Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения - [8]
Эта нехитрая идея указывает на элемент, о котором довольно редко вспоминают при проектировании методологии: "Общность интересов и чувство гражданского долга" должны быть в списке основных идей и параметров разработки проекта, по меньшей мере, наравне с "просмотром кода и тестированием". Я был очень рад узнать, что среди нескольких проектов, с которыми мне пришлось работать в последнее время, есть и такие, у которых эти две идеи выделены как отдельный вид деятельности. У них эти два принципа служат для поддержания каналов для межличностного общения (излишне говорить, что во всех этих проектах основной упор делается на непосредственное, личное общение между разработчиками). Впрочем, я еще не видел, чтобы эти принципы были официально включены в описание какой-либо методологии или рабочего процесса.
Второй "режим успешной работы" - это когда люди берут инициативу в свои руки. Этот принцип работает в полном соответствии с двумя другими - чувством гражданского долга и хорошей ориентации в ситуации . Вместе все три приводят к тому, что все считают самой обычной причиной успеха в работе: "в ключевой момент разработки несколько человек взяли на себя инициативу".
"Хорошо ориентироваться в текущей ситуации" - фраза довольно неопределенная, но имеющая далеко идущие последствия. Люди, которые занимаются сортировкой документов, часто просто раскладывают все бумаги на маленькие кучки (используя при этом сортировку методом Шелла). Самое удивительное заключается в том, что нередко они не разбирают эти кучки дальше, на отдельные документы. Часто приблизительного знания вполне достаточно, ведь в случае необходимости они всегда могут пролистать ту или другую кучку и найти требуемое (будущие исследования покажут нам, какие мнемонические техники для этого используются).
Вот пример уже из области разработки ПО. Мы пытаемся сделать документацию по проекту качественной, обновляем устаревшие версии. Однако, зная, что непостоянство - один из наиболее обычных "режимов сбоя" у человека, можно смело предсказать, что документация все равно не будет обновляться достаточно часто. Что касается меня, то я еще не видел ни одного успешно завершившегося проекта, у которого была бы в порядке документация (за исключением тех случаев, когда код или документация создавались автоматически). Зато видел проект, который потерпел крах именно потому, что разработчикам велели обновлять всю документацию после каждого внесенного изменения. Стоимость разработки при этом настолько выросла, а производительность так упала, что проект пришлось вскоре закрыть.
Я спрашивал тех, кто занимается поддержкой системы, как им удается вносить в программу изменения, пользуясь устаревшей документацией. Они отвечают, что "смотрят тут и там", то есть они в любом случае не станут полагаться на документацию. Они будут читать программный код.
Теперь я уже знаю, что на способность людей "хорошо ориентироваться в ситуации" вполне можно положиться - и при разработке проекта, и при разработке методологии.
Поскольку создавать и поддерживать документацию, которая соответствовала бы текущему положению дел в системе, слишком дорого (особенно учитывая неспособность человека к рутинным действиям), я предложил бы поддерживать документацию на "довольно хорошем" уровне. Иными словами такой, чтобы в ней всегда можно было приблизительно понять, где искать более конкретную информацию. А для остального достаточно будет даже небольших способностей и усердия. Впрочем, "довольно хорошее" состояние документации - невыполнимая задача для большинства проектов (тем не менее, это каким-то образом не играет большой роли, поскольку человек скорее спросит того, кто знает, а не будет рыться в документации).
Трюгве Реенскауг рассказал мне как-то еще одну историю. Однажды он предложил систему автоматического проектирования инженеру, который занимался разработкой морских нефтедобывающих платформ. Трюгве предложил, чтобы система автоматически отслеживала все виды работ, которые проводились на любой части платформы, и указывала их показатели. Однако в ответ услышал: "Достаточно будет, чтобы в системе хранились только номера телефонов. Я сам позвоню и узнаю, что было сделано".
В методологии я обозначаю это термином "невысокая точность" (low precision) [Co98]. Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".
Создание артефактов с низкой степенью точности позволяет снизить стоимость работ за счет сильных качеств человеческой натуры. Для этого нужно делать особый упор на таких свойствах, как "хорошая ориентация" и непосредственная межличностная коммуникация, и стараться не обращать внимания на то, что обновления происходят не так часто, как нужно. Я использую эти принципы с 1994 года, и могу смело рекомендовать их как главный методологический элемент.
Как только мы пытаемся разобраться, "из чего же состоит методология", сразу становится понятно, что методологий должно быть много. При этом для каждого конкретного проекта "оптимальной" будет одна какая-то методология. Более того, все люди обладают разными склонностями, которые обусловлены их жизненным опытом, страхами и принципами. При выборе методологии особое внимание нужно уделять трем основным факторам: размеру команды разработчиков, критичности проекта для компании и его приоритетности. Помимо этого, на результат будут оказывать влияние как культурные ценности команды, так и индивидуальные характеристики ее членов.
Парное, или совместное, программирование является процессом создания программного обеспечения двумя программистами, работающими бок о бок за одним компьютером. С помощью опросов и специальных экспериментов авторы этой статьи исследовали положительные и отрицательные стороны такого стиля работы. Они обнаружили, что при парном программировании время разработки увеличивается на 15%, но при этом улучшается дизайн системы, уменьшается количество дефектов, снижается риск, связанный с занятостью в проекте определенных сотрудников, растет технический уровень команды, улучшается взаимодействие и коммуникация, а кроме того, сам процесс работы в целом доставляет гораздо больше удовольствия.
Можно ли подчинить себе разум и управлять им, словно компьютером? Известный писатель и предприниматель Джон Харгрейв уверен, что да! Он разработал трехнедельную программу, которая позволит стать настоящим хакером своего собственного мозга. Как и программное обеспечение, разум можно взломать – и перенастроить его на нужный лад, чтобы стать успешнее, здоровее, спокойнее и счастливее. А оригинальные рекомендации автора и его неподражаемый юмор сделают процесс «взлома» невероятно увлекательным!
Проект-менеджерам (и тем, кто мечтает стать начальником) посвящается.Писать тонны кода сложно, а управлять людьми еще сложнее! Так что вам просто необходима эта книга, чтобы научиться делать и то, и другое. Можно ли объединить прикольные истории и серьезные уроки? Майклу Лоппу (также известному в узких кругах как Рэндс) это удалось. Вас ждут выдуманные истории о выдуманных людях, обладающих невероятно полезным (хотя и выдуманным) опытом. Именно так Рэндс делится своим разнообразным, порой странным опытом, полученным за годы работы в крупных IT-корпорациях: Apple, Pinterest, Palantir, Netscape, Symantec и др.
CEO Microsoft Сатья Наделла рассказывает историю компании, личную историю и делится размышлениями о технологиях, которые скоро преобразят мир. Это книга для всех, кого интересует история крупнейшей технологической корпорации XX века и кого волнует будущее цифрового мира. На русском языке публикуется впервые.
Вы работаете в команде или возглавляете ее? Тогда вы наверняка не раз задавались вопросом, как наладить эффективное общение членов команды, которое повысит ее способность решать рабочие задачи. И правильно делали. Ученые доказали, что квалификация сотрудников — еще не все, решающее значение для успеха коллектива имеют личные отношения внутри него. Эта книга посвящена технике построения этих отношений. Минимум историй, только работающие алгоритмы и технологии, которые гарантированно помогут вам «прокачать» мощный ресурс эффективности ваших коллег — и вашей собственной.
Сложно найти человека, который не смотрел мультики компании Pixar. Но как крошечная рекламная студия превратилась в гиганта киноиндустрии? Это история о сильных людях и волевых решениях, о выборе и об абсурдных спорах, позволивших истории случиться. Она о том, как грамотное управление и контроль над ситуацией могут противостоять любым рискам. Благодаря этой книге вы узнаете, что стало движущей силой Pixar и как ей удалось справиться с многочисленными трудностями.
Старейший в мире и лучше всего организованный конгломерат раскрывает свои тайны менеджмента перед всеми, кто готов ими воспользоваться. В отличие от других бизнес-пособий, данная книга избавлена от теоретического пустословия и представляет вниманию читателей философию лидерства, на которой основана и в соответствии с которой на протяжении многих веков успешно управляется Империя мафии, неуклонно раздвигающая свои границы. Для широкого круга читателей.