Скотт Беркун - Искусство управления IT-проектами

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

После этого обнаружилось, что всем другим конструкциям нужен тот же самый (!) компонент. Затем, когда мы поступились функциональностью, которая обеспечивалась пресловутым компонентом (то есть сократили требования), мы узнали, что от нас зависит работа других программистов, которым мы должны были обеспечить эту функциональность посредством разработанного нами кода. Злосчастный компонент оказался куда более важным для проекта, чем мы первоначально предполагали. Нам пришлось засесть всей командой за расчеты, сможем ли мы разработать конструкцию и обеспечить нужную функциональность своими силами либо справиться с последствиями при отсутствии данной функциональности.

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

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

Применительно к практике проектирования, итерация означает два шага вперед, шаг назад. Чем труднее и сложнее работа, тем больше это соотношение стремится к равенству (например, полтора шага вперед на каждый шаг назад). Но пока вы не сделаете этот шаг вперед и не примете какое-нибудь решение («Давайте создавать конструкцию Б !»), вы не сможете вскрыть все проблемы и вопросы. Принятие решений в процессе проектирования, даже если они окажутся неверными, – единственный способ вывести проблемные вопросы на поверхность. Если вы все правильно спланируете, то все равно будете многократно спотыкаться при проектировании, но, пройдя все это, вы значительно повысите свои шансы на успех. Большинство инженерных, конструкторских и научных изысканий следуют тем же принципам, выраженным следующей цитатой Джошуа Ледерберга (Joshua Lederberg), лауреата Нобелевской премии 1958 года:

Количество проб и ошибок огромно… Вы продвигаетесь вперед и назад от наблюдения к теории. Без теории вы не знаете, что именно нужно искать, а проверить теорию, не изучив факты, вы тоже не можете… Я думаю, что в ходе отдельного исследования движения вперед и назад происходят тысячи, и даже миллионы раз.

Вторая проблема, связанная с диаграммой на рис. 6.1, заключается в том, что творческая инерция проекта всегда сильнее ожидаемой неопытными лидерами и руководителями. Оказывается, что для свертывания пространства идей в единственную (удачную) конструкцию нужно приложить куда больше усилий, а для этого потребуются несколько иные навыки, чем они себе представляли. На рис. 6.1 дается верное предположение, что время, затраченное на закрытие пространства решения проблем, должно равняться времени, затраченному на его расширение. Но чем более инновационным или творческим будет проект, тем сложнее рассчитать время существования пространства решения проблем. Причина заключается в инерционности творческой работы.