Теперь когда вы прочитали все о том зачем нужно писать требования и из чего они должны состоять, давайте поговорим о том, кто должен их писать.
Кто должен писать требования?
Давайте я расскажу небольшую историю про компанию Microsoft. Когда Microsoft начала серьезно расти в 1980-х, каждый сотрудник компании читал “Мифический человеко-месяц”– одну из классических книг по управлению в разработке ПО (если вы ее не читали, то я вам ее очень рекомендую). Главная мысль этой книги в том, что добавление новых разработчиков на поздней стадии проекта, приводит к его замедлению, а не ускорению. Причина этого в том, что количество коммуникаций в команде, состоящей из n человек, равняется n(n-1)/2. Эта величина растет как O(n*n).
Разработчики в Microsoft думали о том как им писать программы все большего размера, при этом большинство понимало,что добавление большего количество разработчиков будет неэффективно.
Charles Simonyi, который долгое время был “главным архитектором” в Microsoft, предложил концепт мастеров программистов. Идея была в том, что один такой мастер программист будет отвечать за написание всего кода, но он или она будут полагаться на команду младших программистов как на “рабов кода”. Вместо того, чтобы возиться с отладкой каждой функции, мастер программист будет только прототипировать каждую функцию, создавая некий контур, а потом будет передавать ее одному из младших программистов на реализацию (Конечно, сам Simonyi будет Мастером мастеров программистов). Термин “Мастер Программист” отдавал средневековьем и поэтому в Microsoft появились “Менеджеры Программ”.
Теоретически, это решение должно было решить проблему Мифического Человекомесяца, потому что людям уже не надо было постоянно общаться между собой — каждый младший разработчик должен был общаться только с одним менеджером программы и поэтому коммуникации возрастали со скоростью O(n) вместо O(n*n).
Что ж, Simonyi наверное знал Венгерскую нотацию, но не знал Человеческий фактор. Никто не хотел быть рабом кода. Система вообще не работала. В конце концов, Microsoft обнаружила, что несмотря на предположения Мифического Человекомесяца, вы можете добавлять в команду умных людей и получать увеличение производительности, хотя средняя производительность при этом падает. Команда Excel состояла из 50 разработчиков, когда я состоял в ней, при этом ее производительность была выше, чем у команды из 25 разработчиков — хотя и не в 2 раза выше.
Идея с мастерами(господами)/рабами разработчиками была дискредитирована, но в Microsoft все равно остались люди, которых называли менеджерами программ. Умный человек по имени Jabe Blumenthal фактически переизобрел позицию менеджера программы. Отныне менеджер программы будет владеть проектированием и требованиями к продукту.
С тем пор, менеджеры программ в Microsoft собирают требования, определяют какой код будет их реализовывать, и пишут требования.Обычно на каждого такого менеджера программ приходится около 5 программистов; эти программисты отвечают за имплементацию в коде того, что им менеджер программы описал в требованиях. Менеджер программы также координирует маркетинг, документацию, тестирование, локализацию и все остальные надоедливые детали, на которые не должны тратить время программисты. Считается, что у менеджера продукта есть “общая картина” кампании в голове, в то время как программисты могут сосредоточится на правильном написании каждого кусочка кода.
Менеджеры программ неоценимы. Если вы когда-нибудь жаловались на то, что программисты больше заботятся о технической элегантности, чем о конкурентоспособности, вам нужен менеджер программ. Если вы когда-нибудь жаловались на то, что люди, которые умеют писать хороший код, никогда не уделяют внимания корректному грамотному английскому, вам нужен менеджер программы. Если вы когда-либо жаловались на то, что ваш продукт кажется дрейфующим без какого-либо четкого направления, вам нужен менеджер программы.
Как нанять менеджера программы?
У большинства компаний даже нет такой роли как менеджер программы. Я думаю это очень плохо. В мое время, группы в Microsoft с сильным менеджером программы делали очень успешные продукты: мне приходят в голову Excel, Windows 95 и Access. Но другие группы (такие как MSN 1.0 и Windows NT 1.0) управлялись разработчиками, которые игнорировали менеджеров программ (которые были недостаточно хорошими и, скорее всего, заслуживали такого обращения), и их продукты не стали успешными.
Вот три главные вещи, которые вам нужно избегать.
- Не повышайте разработчика до менеджера программы. Навыки хорошего менеджера (грамотный простой Английский язык, дипломатия, знания о рынке, сопереживание пользователям и проектирование UI) очень редко встречаются у хороших разработчиков. Конечно, есть люди которые могут делать и то и другое, но они очень редки. Награждать хорошего разработчика, назначая его на совершенно другую позицию, которая включает написание хороших текстов на Английском, а не на C++, это классический кейс Принципа Питера: люди, как правило, повышаются до уровня их некомпетентности.
- Не давайте маркетологам стать менеджером программы. Без обид, но я думаю, что мои читатели согласятся с тем, что хорошие маркетологи очень редко разбираются в технических деталях проектирования продуктов.
В принципе, управление программой — это отдельное направление в карьере. Все менеджеры программ должны быть достаточно технически подкованными, но им не надо быть отличными разработчиками. Менеджер программ изучает UI, встречается с клиентами и пишет требования. Им нужно ладить с широким кругом людей — от “занудных” клиентов до раздражающих программистов-отшельников, которые приходят на работу в униформе Star Trek, до напыщенных продавцов в костюмах за $2000. В некотором смысле, менеджеры программ — это клей в команде разработки. Харизма критична. - Не заставляйте разработчиков отчитываться перед менеджером программы. Это коварная ошибка. В роли менеджера программы в Microsoft я спроектировал Visual Basic (VBA) для Excel и написал подробные требования, в мельчайших деталях, как VBA будет реализован в Excel. Мои требования составили около 500 страниц. В разгар разработки Excel 5.0, каждый день на работу приходило 250 человек (я оценивал это каждое утро), которые работали над реализацией моих требований. Я не знал почти никого из этих людей, но было около дюжины людей в команде Visual Basic, которые документировали эту функциональность, не включая команду, писавшую документацию со стороны Excel, или одного человека, который тратил полный рабочий день на проверку всех гиперссылок в файле помощи. Самое странное было в том, что я был “на дне” дерева начальников. Именно так. НИКТО мне не подчинялся и не отчитывался передо мной. Если я хотел, чтобы люди что-то сделали, мне нужно было убедить их, что это будет правильным решением. Когда ведущий разработчик Ben Waldman не хотел делать что-то, что я описал в требованиях, он просто этого не делал. Когда тестировщики жаловались на что-то, что я записал в требованиях невозможно нормально протестировать, мне приходилось упрощать требования. Если бы кто-то из этих людей мне подчинялся, то финальный продукт не был бы так хорош. Кто-то из них наверняка бы подумал, что спорить с начальником неуместно. В других случаях, я бы настаивал на своем и приказывал бы им сделать так, как я хочу, из тщеславия или близорукости. Как бы то ни было, у меня не было выбора, кроме как достичь консенсуса. Эта форма принятия решений была лучшим способом сделать все правильно.
Последняя статья в моей серии о требованиях рассказывает о том, как писать хорошие требования, которые люди хотят читать.