Часть 3 - Но... как?

From The Joel on Software Translation Project

Автор: Joel Spolsky
среда, 4 октября 2000г.
Painless Functional Specifications – Part 3: But... How?
Перевод – Дмитрий Бакай (и не только он)</br> Последняя редакция – 4 марта 2006 г.

Теперь, когда вы прочли о том, зачем вам нужны спецификации (Часть 1 - А зачем?) и что у них внутри (Часть 2 - Что внутри?), давайте побеседуем о том, кто их должен писать?

Кто пишет спецификации?

Позвольте мне здесь маленькую историю про Microsoft. Когда в 1980-е у Microsoft начался серьезный рост, каждый там прочел «Мифический человеко-месяц» (The Mythical Man-Month by Frederick P. Brooks, 1975). Суть этой книги в том, что когда вы добавляете больше программистов в запаздывающий проект, он опоздает еще больше. Потому что, когда у вас в команде n программистов, то количество связей для их общения равно n(n-1)/2, которое растет как O(n²).

Итак, программисты Microsoft были озабочены тем, как писать все большие и большие программы, когда наивысшей мудростью дня было, что добавление программистов все только ухудшает.

Чарльз Симони (Charles Simonyi, фамилия венгерского происхождения) – длительное время «главный архитектор» Microsoft – выдвинул идею мастеров-программистов (прим. перев.: игра слов - master может означать "мастер, специалист" или "господин, хозяин"). В основном идея была в том, что один мастер-программист будет ответственным за написание всего кода, но он или она будут полагаться на команду младших программистов как «кодирующих рабов». Вместо того чтобы переживать об отладке каждой функции, мастер-программист в основном писал бы «рыбу» каждой из функций, создавая голый костяк, и перебрасывал его младшим программистам для рабочего наполнения. (и конечно, Симони был бы тогда мастером мастеров-программистов.) Термин «мастер-программист» было несколько излишне средневековым, так что в Microsoft испльзовали «Менеджер проекта».

Теоретически предполагалось, что это решит проблему Мифического человеко-месяца, потому что никому не нужно еще кем-то общаться – каждый младший программист должен общаться тольо с одним менеджером проекта, и, таким образом, число коммуникационных связей растёт как O(n), а не O(n²).

Симони наверняка знал Венгерскую нотацию, но он не знал про "Человеческий фактор в программировании" (Peopleware) (прим. перев.: Симони – создатель венгерской нотации, см. об этом статью Как заставить неправильный код выглядеть неправильно). Никто не хочет быть рабом-кодировщиком. Система абсолютно не работала. Со временем Microsoft обнаружила, что, несмотря на утверждение, что человеко-месяц это миф, вы все еще можете добавить в команду толковых людей и получить лучшие результаты, хотя и при меньших предельных значениях. В команде Excel, когда я там был, насчитывалось 50 программистов, и она была продуктивней, чем была бы команда из 25 – но не вдвое продуктивней.

Идея программистов - мастеров и рабов была дискредитирована, но в Microsoft оставались люди, называемые менеджерами проектов. Пока однажды умный человек по имени Джейб Блументаль (Jabe Blumenthal) не изменил существенно суть этой должности. Впредь менеджеры проектов стали заниматься дизайном и спецификациями продукта.

С тех пор менеджеры проектов Microsoft собирали требования, решали, что должен делать код, и писали спецификации. На каждого менеджера проекта обычно приходилось по 5 программистов; эти программисты отвечали за реализацию в коде того, что руководитель группы программистов реализовал в форме спецификаций. Менеджеру проекта также нужно было согласовывать маркетинг, документирование, тестирование, локализацию и все прочие досадные мелочи, на которые программист не должен тратить свое время. Предполагалось, что у менеджера проекта в Microsoft будет в мыслях «общая картина» компании, в то время как программисты вольны сосредоточиться на создании их кусков кода совершенно верными.

Менеджеры проектов неоценимы. Если вы жалуетесь, что программисты больше заботятся о техническом изяществе, чем о рыночной привлекательности, вам нужен менеджер проекта. Если вы жалуетесь, что люди, которые могут написать хороший код, не в ладах с литературным языком, вам нужен менеджер проекта. Если вы жалуетесь, что кажется, будто ваш продукт блуждает без четкого направления, вам нужен менеджер проекта.

Как вам нанять менеджера проекта?

Многие компании не имеют даже понятия о менеджере проекта. Я думаю, что это очень скверно. В мое время у групп Microsoft с сильными менеджерами проекта были очень успешные продукты. Припоминается Excel, Windows 95 и Access. А другие группы (такие как MSN 1.0 и Windows NT 1.0) были ведомы разработчиками, которые зачастую игнорировали менеджеров проекта (которые, к слову сказать, не были так хороши и, возможно, заслужили пренебрежение), и их продукты были не так успешны.

Вот три вещи, которые следует избегать:

1 Не выдвигайте кодировщика на должность менеджера проекта. Умения необходимые, чтобы быть хорошим менеджером проекта (грамотный русский язык, дипломатия, понимание рынка, сопереживание пользователю и хорошие идеи пользовательских интерфейсов), это очень редко умения хорошего кодировщика. Конечно, некоторым удается и то и другое, но это редкость. Стоящие хорошие кодировщики, продвинутые на другую должность, которая заставит их писать на русском, а не на C++, это классический случай Принципа Питера): работники двигаются вверх по карьерной лестнице до своего уровня некомпетентности.

2 Не позволяйте маркетологам быть менеджерами проектов. Не в обиду, но, я думаю, мои читатели согласятся, что у хороших маркетологов редко есть хорошое понимание в вопросах технологий, достаточное, чтобы придумать продукт.

По существу, менеджер проекта – это отдельный путь карьеры. Все менеджеры проектов должны быть технически очень грамотными, но они не обязаны быть хорошими кодировщиками. Менеджеры проектов вникают в пользовательский интерфейс, встречаются с клиентами и пишут спецификации. Им надо ладить с очень разными людьми – от «слабоумных» клиентов до раздражающих отшельников-программистов, которые приходят на работу в форме из сериала «Star Trek» и до напыщенных менеджеров по продажам в 2000-долларовых костюмах. В чем-то менеджер проекта подобен клею в команде программистов. Харизма - вот ключевой элемент.

3 Кодировщики не должны отчитываться менеджеру проекта. Это коварная ошибка. Как менеджер проекта Microsoft я придумывал стратегию Visual Basic (VBA) для Excel и полностью расписывал её до мельчайших подробностей, как VBA будет реализован в Excel. Моя спецификация разбухла примерно до 500 страниц. На пике разработки для Excel 5.0 я оценил, что каждое утро примерно 250 человек приходили на работу и в основном претворяли в жизни эту громадную спецификацию, которую я написал. У меня не было ни малейшего представления, кто все эти люди, но было около дюжины людей в команде Visual Basic исключительно и только пишущих документацию по нему (не считая команды, пишущей документацию со стороны собственно Excel, или сотрудника с полной занятостью, отвечающего за перекрестные ссылки в файле справки). Невероятным было то, что я был на самом дне иерархии отчетности. Да, да. НИКТО мне не отчитывался. Если я хотел, чтобы люди что-то сделали, то нужно было убедить их, что это как раз то, что нужно сделать. Когда Бен Валдман (Ben Waldman), ведущий разработчик, не хотел делать что-то, что я занёс в спецификацию, он просто-напросто не делал этого. Когда тестеровщики жаловались, что я указал в спецификации нечто, что невозможно полностью протестировать, я должен был упростить это. Если бы хоть кто-то из этих людей был бы должен мне отчитываться, продукт не получился бы таким хорошим. Кое-кто из этих людей счёл бы неуместным предугадывать вышестоящего. Иной раз я мог бы просто надавить и, по самомнению или близорукости, приказать им делать по-моему. Но все было устроено так, что у меня не было другого выбора, кроме достижения единодушного согласия. Такая форма принятия решений была лучшим способом начать получать правильные вещи.

Завершающая статья моей серии о спецификациях говорит о том, как писать хорошие спецификации, которые люди хотят читать.