Непоследовательность - обычная причина режима сбоя у человека. Существуют методологии, которые требуют от своих адептов строгой последовательности действий. Такие методологии я называю "высоко дисциплинированными". Как показывают опросы, проводимые в различных проектах, именно такие методологии наиболее уязвимы, однако в некоторых проектах они используются довольно успешно. Вот пример применения методологии PSP в организации с пятым уровнем CMM. Мне он кажется весьма поучительным: [Web]:
Летом 1996 года небольшую группу программистов ознакомили с методологией PSP. Несмотря на то, что все были настроены относительно обучения весьма положительно, сразу после его окончания новая методология стала использоваться все меньше и меньше. Вскоре никто из тех, кто специально обучился этой методологии, не использовал ее в работе. Когда этих людей спросили, почему они не используют PSP, ответ был практически один и тот же: "PSP - очень строгая методология, поэтому если никто не требует от меня отчета, мне проще работать по-старому".
Чтобы такого не случилось, в методологиях, требующих высокой дисциплины, должны существовать некие регулирующие элементы, которые заставляли бы людей быть более последовательными. В методологии "Cleanroom" есть правило, запрещающее компиляцию, которое подкреплено определенным способом управления. Для Extreme Programming необходим "наставник" ("coach"), который следит за соблюдением всех предписаний этой методологии. В PSP такие функции не были предусмотрены, поэтому неудивительно, что группа разработчиков из нашего примера перестала ей пользоваться - у этой методологии просто не было никакой структуры поддержки. Предполагается, что эти факторы будут предусмотрены в TSP [Web].
Однако, несмотря на все это, существуют люди, которые могут на протяжении длительного времени делать свою работу последовательно и дисциплинированно (это лишний раз показывает, насколько все мы отличаемся друг от друга). Иногда для того, чтобы повлиять на дисциплинированность группы достаточно поменять ее руководителя. Спасибо Трюгве Реенскаугу (Trygve Reenskaug) за историю, которая прекрасно показывает, как стиль управления влияет на личные качества:
Недалеко отсюда был маленький галантерейный магазинчик, жуткое место. Товар в беспорядке, продавщицы полируют ногти или болтают по телефону, на покупателей никто не обращает внимания. Вскоре он закрылся, и на том же месте открылся другой магазин. О, тут дела пошли по-другому! Этот магазин был чистый, аккуратный, продавщицы всегда предупредительны… Только вот странное дело - продавщицы ведь были те же самые!
На самом деле хорошо известно, что личный стиль руководителя имеет огромное значение. Году в 1997 те, кто работал над проектом Chrysler Comprehensive Compensation [C3] узнали это на собственном опыте. Сначала основными принципами разработки были "думать наперед", "нечеткое, но растяжимое планирование" и "программный код - личное дело разработчика". Затем вся команда перестроилась (главной движущей силой этих перемен был Кент Бек (Kent Beck)), и основными принципами стали "делайте все простым и понятным, потом можно внести необходимые дополнения", "весь код должен быть общедоступным, и любая пара программистов может вносить в него любые изменения". Таким образом, одни и те же люди смогли принять совершенно новые для себя принципы работы и пройти путь от полного беспорядка, отсутствия коммуникации и невыполнения обязательств по поставкам к последовательному применению новой высокодисциплинированной методики и регулярному выполнению обязательств в течение трех лет работы.
Чувство гражданского долга и способность ориентироваться в ситуации
Проблема человеческого непостоянства относится к так называемому "режиму сбоя", но у человека есть еще и "режимы успешной работы". Вот три их разновидности:
как правило, человек имеет чувство гражданского долга,
человек предпочитает брать инициативу в свои руки,
человек хорошо ориентируется в окружающей обстановке. Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект". Вот один из таких типичных ответов, который опубликован NASA в работе "Deorbit flight software lessons learned" ("Уроки, полученные в результате работ над программным обеспечением для увода космических кораблей с орбиты") [NASA]:
Возможно, наиболее важным (в долгосрочном плане) фактом являлось то, что в процессе работы над проектом образовалась сплоченная команда разработчиков, способная осуществлять быструю разработку систем GN amp;C. Формирование команды складывалось из поиска новых талантливых людей, их обучения, накопления опыта работы с инструментарием, процессом и методологией, и последующей интеграцией в единый спаянный коллектив.
Поработав вместе над проектом целый год, вся команда приобрела хорошие знания в предметной области, а также в методах и средствах разработки. Создание атмосферы дружбы и взаимопомощи среди разработчиков способствовало их взаимному обучению и всячески поощряло его. Готовность членов команды заниматься любым и всеми аспектами проекта многократно оказывалась бесценным подспорьем в работе… (курсив мой, А.К.)
…такая команда будет необходима в дальнейшем и данному отделу, и всему агентству".
Что заставило людей вести себя таким образом? Одна из возможных причин - чувство гражданского долга.
Может быть, наши проекты чаще заканчивались бы успехом, если бы мы просто старались усилить "чувства общности интересов и гражданского долга" в команде разработчиков. Впрочем, я не хочу сказать, что это основная моя рекомендация, потому что в среднем эти чувства и так хорошо развиты, и плохие руководители не упускают случая, чтобы этим воспользоваться (см, к примеру, "Death March" [Yo]).
Эта нехитрая идея указывает на элемент, о котором довольно редко вспоминают при проектировании методологии: "Общность интересов и чувство гражданского долга" должны быть в списке основных идей и параметров разработки проекта, по меньшей мере, наравне с "просмотром кода и тестированием". Я был очень рад узнать, что среди нескольких проектов, с которыми мне пришлось работать в последнее время, есть и такие, у которых эти две идеи выделены как отдельный вид деятельности. У них эти два принципа служат для поддержания каналов для межличностного общения (излишне говорить, что во всех этих проектах основной упор делается на непосредственное, личное общение между разработчиками). Впрочем, я еще не видел, чтобы эти принципы были официально включены в описание какой-либо методологии или рабочего процесса.
Второй "режим успешной работы" - это когда люди берут инициативу в свои руки. Этот принцип работает в полном соответствии с двумя другими - чувством гражданского долга и хорошей ориентации в ситуации . Вместе все три приводят к тому, что все считают самой обычной причиной успеха в работе: "в ключевой момент разработки несколько человек взяли на себя инициативу".
"Хорошо ориентироваться в текущей ситуации" - фраза довольно неопределенная, но имеющая далеко идущие последствия. Люди, которые занимаются сортировкой документов, часто просто раскладывают все бумаги на маленькие кучки (используя при этом сортировку методом Шелла). Самое удивительное заключается в том, что нередко они не разбирают эти кучки дальше, на отдельные документы. Часто приблизительного знания вполне достаточно, ведь в случае необходимости они всегда могут пролистать ту или другую кучку и найти требуемое (будущие исследования покажут нам, какие мнемонические техники для этого используются).
Вот пример уже из области разработки ПО. Мы пытаемся сделать документацию по проекту качественной, обновляем устаревшие версии. Однако, зная, что непостоянство - один из наиболее обычных "режимов сбоя" у человека, можно смело предсказать, что документация все равно не будет обновляться достаточно часто. Что касается меня, то я еще не видел ни одного успешно завершившегося проекта, у которого была бы в порядке документация (за исключением тех случаев, когда код или документация создавались автоматически). Зато видел проект, который потерпел крах именно потому, что разработчикам велели обновлять всю документацию после каждого внесенного изменения. Стоимость разработки при этом настолько выросла, а производительность так упала, что проект пришлось вскоре закрыть.