Еще одно наблюдение за годы работы над софтверными проектами, особенно – e-commerce.
Самый большой риск проекта – это затягивание сроков. Как следствие – бюджета. Неважно по чьей инициативе – клиента или разработчика. Если сроки плывут – каждый день возрастает риск того, что проект вообще не будет закончен никогда, деньги не будут получены, клиент останется недовольным и проч. После определенного момента у обоих сторон падает интерес.
Бизнес сейчас таков, что если за, скажем, четыре месяца не запустил новый продукт (сайт, магазин или что-то еще), то объем изменений за это время накапливается такой, что еще чуть-чуть и правильнее надо будет все выбрасывать и делать заново. Разумеется, на это никто не идет, и система обрастает заплатками.
Более того – чем длиннее проект, тем больше вероятность, что клиент поменяет мнение, что ключевые люди клиента поменяются, что поменяется рыночная ситуация, да в нашей стране что угодно может произойти. Поэтому все надо делать быстро.
Вторая проблема заключается в том, что когда проект встал (неважно по какой причине – клиент тормозит с предоставлением данных или разработчик что-то не успевает), затраты на ФОТ продолжают есть бюджет проекта. Если компания-разработчик ради экономии сокращает выделенные на проект ресурсы (перебрасывает кого-то на другой проект), то у команды падает интерес и мотивация все закончить в срок и сделать хорошо.
Но как уместить большой проект в небольшие сроки? Тут многие допускают большую ошибку – создают избыточно большую команду. Пушить ресурсами можно только вытягивая из болота проект, но никак не в нормальном его плане. Большая команда увеличивает число коммуникаций в проекте, которые за собой тянут объем документации и пронизывающие эту документацию противоречия и неясности.
Поэтому мы стараемся сделать все очень компактно и стараться не раздувать команду без очень большой надобности. К сожалению, ради достижения этой цели приходится смешивать некоторые роли, которые для крупных проектов стоит сделать отдельными в команде. Но если их так сделать, то возникает проблема роста числа коммуникаций и, как следствие, рост сроков и бюджета. А рост сроков – см. пункт 1.
Поэтому для е-commerce-проектов я верю в компактные команды, выделенные на 100%, состоящие только из профессионалов-универсалов, способных в короткое время сделать революционные изменения, запустить, а уж потом можно передавать в спокойную поддержку.
Кстати, мы ищем разработчика (Java/Spring), QA, бизнес-аналитика и системного инженера. Рекомендуйте, у нас хорошо.
Being in America 