Переводика: Форум

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в данную темуНачать новую тему
> Переводы Джоэля Спольски - 4, Как стать менеджером по разработке программного обеспечения
Yukon
сообщение 15.1.2010, 18:03
Сообщение #1


Активный участник
***

Группа: Переводчики
Сообщений: 763
Регистрация: 11.1.2010
Пользователь №: 653



How to be a program manager


http://www.joelonsoftware.com/items/2009/03/09.html

Как стать Program Manager?

Джоэль Спольски, Понедельник, 9 марта 2009 года

Наличие хорошего менеджера ПО (Program manager - PM) – одна из секретных формул разработки по-настоящему выдающегося программного обеспечения. И в вашей команде, вероятно, таковых нет, потому что их нет в большинстве команд.

Чарльз Симоный (Charles Simonyi), выдающийся программист, со-изобретатель принципа редактирования текстов WYSIWYG, встретился с Мартой Стюарт (Martha Stewart), сделавшей миллиарды долларов на акциях Microsoft, и побывавшей в космосе, впервые пытался решить проблему организации команды по разработке действительно большого программного продукта (синдром «Мифического человеко-месяца») созданием супер-пупер-сверхпрограммиста, который бы писал функции верхнего уровня, делегировав написание реализации функций нижнего уровня команде рядовых программистов-новичков по мере необходимости. Они назвали эту должность Program Manager (PM). Симоный гениален, но эта его идея – не очень. Вряд ли кто хотел бы быть рядовым программистом-новичком, по-моему.

(Примечание: Более подробно об этом можно прочитать в книге Вильями Паундстоуна «Как сдивинуть гору Фудзи?»)

Что должен делать PM?

Джейб Блюменталь, программист команды Mac Excel в конце 1980-х, возродил этот термин (PM) для другой работы. Он заметил, что разработка ПО стала настолько сложной, что ни у кого из программистов не хватало времени, чтобы разобраться, как делать программы, которые были бы и полезны, и используемы. Команда маркетологов изрекала тенденциозный вздор о потребностях покупателей, и ни у кого не было времени, чтобы поговорить с ними или перевести их МБА-сленг в нормальный список опций программного продукта. Это была масса материала по дизайну продукта, который требовал массы работы: интервью с пользователями, прогон тестовых примеров, обзор аналогичных продуктов конкурентов, и напряженное осмысление того, как сделать вещи проще, и у большинства программистов просто не хватало на это времени (или они просто не были сильны в этом). Блюменталь воспользовался наименованим должности «Program Manager», но изменил эту должность полностью. Что же должен делать PM?

С тех пор, PM обязан:

- Разрабатывать дизайн интерфейса пользователей;
- Писать функциональные спецификации;
- Координировать работу команды;
- Служить адвокатом заказчика и
- Носить брюки банановой республики;

Для маленьких продуктов вам будет достаточно одного PM, но для больших продуктов, вам вряд ли хватит одного. В таком случае каждый из PM может быть ответственным за свой набор опций. Хорошее эмпирическое правило – иметь одного PM на каждую четверку программистов. Если у вас есть сложности при распределении работы, одним из подходов, который я узнал от Майка Конта (Mike Conte), является разделение продукта в соответствии с видами деятельности пользователей (user activities).

Например, Твиттер мог бы быть разделен по видам деятельности пользователей так:
- регистрация и начало работы;
- отправка сообщений и чтение ответов на них;
- настройка вашего профиля;
- поиск новостей.

Моим первым назначением на должность PM в Microsoft была т.н. «кастомизация» работы пользователей в Excel, т.е. разработка языка для написания скриптов и макросов. Первым делом мне нужно было выяснить, в чем нуждаются заказчики (пользователи), что я и сделал, поговорив со столькими пользователями, сколько смог, пока я не начал испытывать скуку, т.к. я уже начал слышать похожие вещи. Я потратил кучу времени, разбираясь с командой, что было бы возможно и резонно сделать в единственном 18-месячном релизе, и я потратил немало времени на выяснение, может ли команда Visual Basic'а предоставить компилятор, редактор исходного кода, и редактор окон диалога, который бы использовался в Excel для нашего макроязыка. Мне также надо было разговаривать с Apple, разрабатывающим свой собственный макроязык под названием AppleScript, и с другими командами по разработке приложений в Microsoft, в основном Word, Access, Project и Mail, которые в основном делали то же самое, что и Excel. Большую долю моей работы заняли встречи и обсуждения. Встречи, переписка по емейлу, телефонные звонки. У меня осталось на всю жизнь множество виртуальных шрамов с тех пор, и я еще вздрагиваю от страха в своем офисе, когда звонит телефон.

Следующим шагом стала задача зафиксировать наше видение: что-то вроде обобщенного документа, где бы говорилось, как VB должен работать в Excel, как должны были бы выглядеть некоторые примеры макросов, и это были основные фрагменты, которые мы должны были сложить вместе, и это было бы то, что решало бы проблемы пользователей. Когда это перестало вызывать слишком большое число возражений, я начал работать над более детальной спецификацией, которая объясняла, опускаясь до мельчайших деталей, как всё это будет выглядеть для пользователя.

Это была функциональная спецификация, но не техническая, которая описывала, как это все будет выглядеть для пользователя, а не то, как это будет сделано. (Прочитайте все о функциональной спецификации здесь –

http://www.joelonsoftware.com/articles/fog0000000036.html)

Честно говоря, тогда я не знал почти ничего. Только что выпущенный из колледжа, я не обладал достаточным опытом для разработки кода, тестирования, написания документации, маркетинга продукта, или создания тестовых примеров. К счастью, у Microsoft были серьезные продвинутые гуру по каждой из этих позиций, которые научили меня всему, что я знаю сегодня, и которые выполнили настоящую работу по производству выдающихся программных продуктов.

Например, я знал, что пользователи хотели бы копировать значение табличной ячейки в переменную:
x = [A1]
и это должно работать. Проблема была в том, что ячейка могла содержать число или строку, но Basic, был языком с ранним связыванием… Вам необходимо объявить переменнуе как целую, или с плавающей точкой, или как строковую, прежде чем вы сможете использовать её.

Поэтому Basic нуждался в нескольких динамических типах, но я не был достаточно крут, чтобы разобраться, как это сделать. Том Корбет (Tom Corbett), программист из команды Visual Basic, разобрался с этим. И так появились Variants и IDispatch, и Бейсик тем динамическим языком, тем, чем ваши дети сейчас называют «утилитарным программированием» (duck typing). Точнее говоря, моя работа состояла не в решении проблемы, а в том, чтобы разобраться с тем, в чем нуждаются пользователи и быть уверенным в том, что программисты разберутся с тем, как это сделать.

Как только спецификация была завершена, и команда разработчиков приступила к работе, у нас появилось две области ответственности: решение всех возникающих вопросов о дизайне, и обсуждение со всеми остальными командами того, что разработчики не обязаны делать. Я встречался с тестерами, объясняя им то, что им нужно делать и помогая им планировать тестирование всего и вся. Я встречался с командой документирования, чтобы быть уверенным, что они понимают, как надо написать хорошее руководство и справочник по Visual Basic. Я встречался с экспертами по локализации, чтобы разобраться с их стратегией. Я сидел с маркетологами, чтобы объяснить им выгоды VBA. Я работал с экспертами по юзабилити, чтобы помочь создать им тесты.

PM должен ходить на множество совещаний, но не должен создавать ничего, кроме написанной спецификации, и это причина того, что зануда-выпускник, кем был я, в принципе был способен выполнить эту работу. Вам не надо быть программистом-ветераном с 14-летним опытом, чтобы выполнять обязанности PM (фактически, наличие 14-летнего опыта программирования будет мешать вам быть хорошим адвокатом пользователей).

Конфликт

В отсутствие PM, ваш типичный супер-умный программист стремится соригинальничать, разработав экзотический и непонятный интерфейс пользователя, который заставить вас почувствовать себя VULCAN’ом (см. рисунок ниже). Типичный крутой программист печально известен как обладатель блестящего ума, который не может придумать альтернативу запоминанию 16 однобуквенных аргументов командной строки. Такие программисты стремятся цепляться за свои первоначальные идеи, особенно, если они уже успели написать для них код.



Одной из лучших вещей, которую PM может добавить к разработке дизайна программного продукта, это альтернативное мнение о том, как он должен быть спроектирован, надеясь на то, что оно будет более эмпатическим к таким ТОРМОЗНУТЫМ ПОЛЬЗОВАТЕЛЯМ, которых их нудное умственное бессилие требует, чтобы приложение могло быть использовано без чтения руководства пользователя, написания пользовательских emacs-lisp функций или перевода в уме чисел в шестнадцатиричную систему.

PM может привнести в разработку дизайна программного продукта ценные идеи, которые сделают его дружественным к обычным пользователям, чьи умственный способности не рассчитаны на чтение мануала, написание макросов, emacs-lisp функций или преобразования в уме десятичных чисел в шестнадцатиричные.

Хороший PM придет со своими собственными предложениями о принципах работы пользовательского интерфейса, которые могут быть лучше, или хуже, чем идеи разработчика. И грядут долгие споры. Как правило, менеджер ПО настаивает на чем-то более простом и легким для понимания пользователя, использующего телепатический пользовательский интерфейс и 30-дюймовый экран, который, однако, помещается в вашем кармане, в то время как разработчик настаивает на том, что наиболее легко реализуется в коде, с интерфейсом командной строки («что такого неудобного в этом?») и Python-связывания.

Одной из наиболее монументальных дискуссий, запомнившихся мне по проекту Excel 5, состоялась между разработчиками, желающими, чтобы pivot (перекрестные) таблицы перемещались по рисованному уровню над таблицей, и PM, который настаивал, чтобы pivot-таблицы находились прямо в ячейке таблицы. Этот спор продолжался довольно долго, пока PM не одержал верх, но окончательный дизайн все-таки стал намного-намного лучше, чем те варианты, которые предлагались в самом начале.

Для гарантии того, что дебаты пройдут в уважительной атмосфере, и будут обосновываться рациональной оценкой фактов, абсолютно необходимо, чтобы PM и разработчики имели равные права. Если разработчики подчиняются PM, то в ходе дебатов рано или поздно ему все это надоест, и PM просто скажет: «ОК, хватит болтать, будем делать по-моему». Если же они будут равны, этого никогда не случится. Это немного похоже на судебный процесс: мы ведь не позволяем адвокату одной из сторон быть судьей, и работаем исходя из того, что истина, скорее всего, будет выявлена в ходе дискуссии на равных. Дебаты могут быть честными, только если ни одна из сторон не имеет привилегий.

Это очень важный момент, так что, если вы сейчас мечтали о Салли из 11 класса, гадая, где же она сейчас, очнитесь. Она физиотерапевт в Скоттдейле, и республиканка. А сейчас внимание. Программисты не должны подчиняться PM, что означает, кроме всего прочего, что лидером команды, или CTO, или CEO, не может быть человек, разрабатывающий спецификации.

Ошибкой номер один, которую делают большинство компаний – это назначить менеджера программистов, который пишет спецификации и разрабатывает дизайн продукта. Это ошибка, потому что дизайн в этом случае не рождается в честном соревновании мнений, конфликта или дебатов, так что он не может стать таким хорошим, каким мог бы.

Я наступил на эти грабли. В компании Fog Creek Software, я сам исполнял множество обязанностей PM, и это был вечный бой – напоминать людям, что это они должны не соглашаться со мной, если я говорю неправильные вещи. Мы не были большой компанией, но, мы в конце концов стали достаточно крупными, чтобы наконец получить настоящих PM, Дэна и Джейсона, и программисты любят спорить с ними.

Конечно, когда программисты уравнены в правах с PM, программисты стремятся одержать верх. И здесь я приведу то, что случалось уже не раз: программист просил меня вмешаться в спор, который он вел с PM:

«Кто будет писать код?» спросил я.
«Ну, я…»
«ОК, кто делает контроль версий?»
«Я, наверно…»
«Так, в чем проблема, конкретно? У вас абсолютный контроль над содержанием каждого бита финального продукта. Что еще вам нужно? Корону?»

Видите ли, оказывается, что такая система возлагает на PM задачу по убеждению программиста, потому что, с одной стороны, PM несет риск, что программист сдастся, и просто станет делать то, что ему нравится. Так что, быть эффективным PM означает, что вы обязаны: а) быть правым б) заслужить уважение программистов, чтобы они признавали вашу правоту.

Как же заслужить это уважение?

Этому способствует, если, будучи PM, вы достаточно хорошо умеете писать программы. Но это нечестно! Ведь не предполагается, что PM будет программировать. Но программисты стремятся уважать программистов больше, чем непрограммистов, не важно, насколько последние умны. Можно быть эффективным PM, не будучи программистом, но заслужить уважения программистов будет гораздо тяжелее.

Примечание: flip the bozo bit . Определить, кто является клоуном, и прекратить его слушать. (Отправить в игнор).

Другим способом заработать уважение команды программистов является ум, открытость идеям, и честность в любых дебатах, которые возникают. Если PM изрекает глупости, то программист может «отправить его в игнор» (установить бозо-флаг). Если PM лично или эмоционально застревает на одной точке зрения, которая становится необоснованной, то это ведет к потере изрядной доли уважения… обе стороны, но особенно PM должен эмоционально отстраняться от дебатов и стремиться рассматривать каждое новое доказательство и изменять свое мнение, когда факты требуют этого. Окончательно, если программисты видят, как PM интригует, ведя секретные переговоры с боссом или пытается разделять-и-властвовать, чтобы выиграть спор, вместо того, чтобы спорить по-честному, они утрачивают к нему доверие.

А когда PM теряет доверие команды программистов, все кончено. Это уже не будет эффективным. Программисты отключаются и делают все по-своему. Это приводит к ухудшению кода и потере времени, т.к. вы не только платите неэффективному PM зарплату, но и неэффективный менеджер собирает совещания и съедает время всех остальных, хотя это не делает код нисколько лучшим.

Спецификации? Серьезно? Это так негибко.

Существует множество организаций по разработке ПО, где спецификации являются символами бездумной бюрократической работы, так что все сейчас обсуждают идею о том, что не спецификации не нужны. Эти люди не имеют цели. Написание функциональных спецификаций является самым сердцем гибкой разработки, потому что это позволяет вам быстро проходить через множество вариантов дизайна до того, как вы напишете код. По сравнению с кодом, написанную спецификацию легко изменить. Сам процесс написания спецификаций заставляет вас обдумывать дизайн, который находится у вас в голове, и помогает вам быстро увидеть изменения в нем, так что вы можете повторять процесс снова и пробовать все новые варианты дизайна. Команды, которые используют функциональные спецификации, получают лучше спроектированные продукты, потому что у них есть возможность быстро исследовать большее число возможных решений. Они также быстрее пишут код, потому что, когда они начинают, у них есть ясная картина того, что должно быть сделано. Функциональные спецификации являются настолько важными, что одним из нескольких твердых и простых правил в Fog Creek является: «Никакого кода без спецификаций» («Нет спецификаций – нет кода»).



Точная форма функциональной спецификации может иметь различное воплощение. Каждая функциональная спецификация должна объяснять, как будет вести себя программа. Она ничего не говорит о том, как код будет работать внутри. Вы начинаете с верхнего уровня: утверждение о видении, не более одной страницы на объяснение сути новой опции. Один раз ухватив смысл, вы можете разработать диаграммы … макетов экранов, показывающих продвижение пользователя по приложению, с подробными заметками, разъясняющими, как это работает. Для многих типов функциональности, особенно для нагруженного пользовательского интерфейса, как только вы получите эти диаграммы, вы выполнили задачу. Это ваша спецификация. (Джейсон Фрид, вы можете идти)

Чтобы научиться писать хорошие функциональные спецификации, читайте мои серии из четырех частей. Если вы хотите увидеть типовую спецификацию, написанную мной, вы можете скачать полную спецификацию проекта Fog Creek Copilot.

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

Как обучиться на PM?

В большинстве случаев, становление PM является вопросом обучения: обучения технологии, людей, и того, как быть эффективным в политической организации. Хороший PM сочетает инженерный подход к технологии проектирования с политической способностью находить консенсус и собирать людей вместе. Пока вы будете работать над этим, есть несколько книг, которые вам следует прочитать:

Насколько я могу судить, книга Скотта Беркуна «Делая вещи» является единственной книгой, где довольно полно написано, что менеджер ПО должен делать, так что начните с неё. Скотт много лет был менеджером ПО команды Internet Explorer.

Другая большая часть обязанностей менеджера ПО – дизайн пользовательского интерфейса. Читайте Стива Круга «Не заставляйте меня думать», затем мою собственную книгу «Дизайн пользовательского интерфейса для программистов».

Наконец, я знаю, что это звучит банально, но книга 1937 года Дейла Карнеги «Как завоевывать друзей и оказывать влияние на людей» является фантастическим введением для развития навыков общения. Это первая книга, которую я заставляю читать всех стажеров в Fog Creek, до всех прочих, и они всегда хихикают, когда я говорю им, что ее надо прочитать, но любят ее, после того как ее прочитают.

Далее идут объявления о летних стажировках для студентов колледжей в фирме автора и т.п..

Сообщение отредактировал Yukon - 20.1.2010, 8:28
Перейти в начало страницы
 
+Цитировать сообщение

Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 18.10.2019, 19:48
Rambler's Top100