Читать книгу Сделано - Скотт Беркун, Scott Berkun, Scott Berkun - Страница 16

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

Однако моя цель в этой главе, да и в книге, не в том, чтобы сравнивать различные методологии. Напротив, я считаю, что нужно овладеть концепциями, на которые они все опираются, чтобы преуспеть с любой из них. Методологию всегда следует адаптировать и корректировать под спецификации каждой команды и проекта, а это возможно, только когда ваши знания намного глубже поверхностных. Итак, если вы прислушаетесь к основным идеям этой главы и книги, вероятность вашей эффективности возрастет, независимо от того, какой методологией вы пользуетесь. Я объясню аспекты некоторых методов, однако если вам нужен подробный анализ, его придется поискать в других источниках[20]. Хотя методы разработки программного продукта важны, это не палочка-выручалочка. Худшее, что можно сделать, – слепо соблюдать правила, которые явно не работают, просто потому, что они указаны в какой-нибудь известной книге или рекомендуются авторитетным экспертом. Зачастую зацикленность на процессе – тревожный признак: она может свидетельствовать о попытке менеджера уклониться от трудностей и ответственности или погрузиться в бюрократические процедуры, которые заменяют настоящие лидерские действия. Более того, одержимость методологией иногда указывает на слабые стороны организации. Как Том ДеМарко пишет в книге «Человеческий фактор»[21]:

Одержимость методологией – еще один пример иллюзии высоких технологий. Люди убеждены, что самое главное – технология. ‹…› Но какими бы ни были технологические преимущества, они возможны лишь за счет значительных жертв со стороны команды.

Сосредоточившись на методе и процедуре, вместо того чтобы выстраивать процедуры в помощь людям, МП приступают к планированию, ограничивая вклад отдельных сотрудников. Они акцентируют внимание на правилах и их соблюдении, вместо того чтобы учить сотрудников думать, адаптировать, совершенствовать эти правила. Так что любую методологию следует использовать крайне осторожно: нельзя навязывать ее команде[22]. Напротив, методология должна поддерживать, стимулировать команду, помогать ей достичь результата (в главе 10 вы найдете советы на эту тему).

Соблюдение (или несоблюдение) сроков никогда не зависит только от выбранной методологии. Существуют факторы, которые влияют на все проекты, и МП должны понять их до того, как составлять график работы. Однако прежде чем обсудить это, давайте перечислим компоненты графика.