Многие компании вынуждены разрабатывать программное обеспечение, и многие среди них совершают ошибки, приводящие к увеличению бюджета проекта в несколько раз. Расскажет о том как удержать бюджет на разработку с помощью простого применения практик проектного управления Андрей Соловьев, IT-предприниматель, эксперт в проектировании программного обеспечения, выпускник бизнес-школы университета Чикаго (Chicago Booth), создатель компании «Smart Software Design».
— Наша компания много лет занимается проектированием программного обеспечения, а также управляет проектами в области разработки программного обеспечения. Мы умеем организовывать в рамках единого проекта одновременную работу нескольких команд разработчиков, определяем требования, которые позволяют реализовать такое сложное взаимодействие, и разрабатываем как общую архитектуру решений, так и проектирование архитектуры баз данных. При этом непосредственно разработку мы не осуществляем — это позволяет нам избегать возможного конфликта интересов между разработчиками и проектировщиками.
Разделение ролей в рамках проектного управления позволяет существенно снизить стоимость разработки программного обеспечения. Но у этого решения есть цена: ответственность за ход и результат реализации проекта должен брать на себя менеджмент заказчика.
Источники проблем, гибкость бюджета разработки
Многие компании сталкиваются с необходимостью создать инструмент, решающий их задачи, и делающий больше, чем простой мессенджер. Например, ПО для взаимодействия на строительной площадке различных участников. Простого обмена сообщениями здесь недостаточно — требуется аутентификация пользователей и авторизация действий, поскольку действия различных компаний, которые работают на стройке, должны иметь юридически значимый характер.
Другой пример — телемедицина. Платформа, которая обеспечивает телемедицинские услуги, должна выполнять ряд требований законодательства.
Нанимать при создании такого инструмента экспертизу, которая внутри организации заказчика контролирует реализацию проекта, получается, зачастую, дорого и долго. Обычно заказчик, не обладающий специалистами нужного профиля в разработке ПО, начинает решать эту задачу с поиска компании-разработчика, потом договаривается с найденным исполнителем, передаёт этой компании свою проблему и ожидает благополучного решения. Минус такого подхода в том, что срабатывают обычные экономические стимулы: уже на этапе проектирования исполнитель старается заложить в смету свою максимальную выгоду, и это, конечно же, приводит к многократному удорожанию стоимости разработки.
Мы выделяем три проблемные области, которые увеличивают стоимость разработки для заказчика:
- Проектирование архитектуры решения
- Выбор технологического стека решения
- Организация разработки — структура требований
Для каждой проблемы существует свое решение, но в большинстве своём они связаны с банальным применением давно известных практик проектного управления. Какова цена вопроса? Исходя из нашего опыта, мы говорим об однозначном множителе.
Точнее — делителе, который в итоге применяется к оригинальному бюджету, собранному заказчиком от разработчиков. Наш рекорд — снижение в 6,5 раз: со 190 тысяч долларов до 30 тысяч долларов без изменения конечного функционала. Это разница между первоначальным бюджетом, полученным заказчиком с рынка, и бюджетом, который был принят в качестве приложения к договору между заказчиком и выбранным исполнителем в результате применения практики разделения ролей в проекте.
Проектирование архитектуры решения
Приведу пример исполнителя — строителя: если поручить строителю разработать проект здания, то с высокой долей вероятности можно быть уверенным, что многие остатки на складе этого строителя найдут своё место в таком проекте, пусть даже все эти «излишества» заказчику, в принципе, и не нужны. Для разработчика программного обеспечения таким складом выступает «репозиторий» — специализированное хранилище ранее написанного кода, размещаемое во внутреннем контуре разработчика. Разработчик имеет дополнительный стимул как можно чаще использовать код, написанный им ранее.
Стимулом является в разы более низкая трудоёмкость адаптации такого кода по сравнению с написанием его заново. Репозиторий позволяет разработчику продать один и тот же функционал несколько раз. Это очень мощный механизм увеличения рентабельности при выполнении проектов на заказ, и нельзя обвинять исполнителя в том, что он старается максимально увеличить свою прибыль.
Однако необходимо понимать, что фокус внимания исполнителя, нацеленный на собственный финансовый результат, не всегда равнозначен его стремлению достичь оптимальный результат для заказчика. Вполне возможно, что заказчик получит излишне дорогое решение, и, не имея соответствующей экспертизы, будет вынужден согласиться с предлагаемым решением от исполнителя. Один из многочисленных примеров такого подхода со стороны разработчиков-исполнителей — бесконечные сервисы авторизации, написанные для одного проекта. При этом существуют Open Source решения (читай — бесплатные), на разработку и тестирование которых сообщества независимых разработчиков потратили много человеко-лет.
Таких коллизий можно избежать за счёт разделения ролей между исполнителями-участниками проекта, например, проектировщик и разработчик. Тогда проектированием архитектуры будущего решения занимается отдельный участник процесса, который не зарабатывает на проданных заказчику часах разработки.
Выбор технологического стека решения
Яндекс в одной из своих презентаций говорил о том, что при обслуживании сравнимого числа запросов код на С++ требует в четыре раза меньше ядер, чем код, написанный на Питоне. Выбор технологического стека напрямую влияет на параметры финансовой модели, которая учитывает параметры реализации проекта заказчика, среди прочего — затраты на аренду «железа» при эксплуатации ПО.
Передавая «под ключ» реализацию проекта одному исполнителю, заказчик вручает в его руки выбор технологического стека. Репозиторий, которым обладает исполнитель, толкает его на рекомендацию ранее использованных решений. На выбор технологического стека должны влиять факторы, важные для заказчика — стоимость эксплуатации получаемого программного обеспечения, а также стоимость, скорость разработки и ввода его в эксплуатацию.
Исполнитель-разработчик, которому довелось определить технологический стек, старается минимизировать свои риски — избегает необходимости делать что-то, что не умеет, даже если это «что-то» трижды нужно заказчику. И стремится выбирать решения, которые максимально увеличивают количество часов разработки, за которые платит заказчик, и при этом сводят собственные усилия к минимуму (опять репозиторий!). Будем держать в голове, что такой подход не является злонамеренным. Таковы стимулы, созданные нормальными, обычными бизнес-интересами исполнителя-разработчика.
Решение этой проблемы всегда очень простое — нужно получить второе мнение о предложении по технологическому стеку от исполнителя-разработчика. Или выбирать технологический стек без участника, который будет его непосредственно делать. Иными словами, разделение ролей в проекте — вот что снова становится решением проблемы.
Организация разработки — структура требований
Решение не покупать склад разработчика (пресловутый репозиторий) приводит к необходимости создания требований, которые можно передавать для разработки исполнителю-разработчику.
Требования нужно делать в формате, понятном бизнесу, а именно — заказчику. Они должны иметь модульную структуру — для того, чтобы максимизировать потенциальное переиспользование кодовой базы. В качестве примера рассмотрим механизм уведомлений: требования к нему должны быть написаны один раз для всего создаваемого ПО, механизм уведомлений необходимо реализовать тоже один раз, после чего этот механизм может быть использован в любой точке ПО — для уведомления любого пользователя этого программного обеспечения.
Модульные требования позволяют сформировать сущностную структуру управления проектом, а именно — определить приоритеты разработки функционала создаваемой системы, что особенно важно при выводе создаваемого ПО на конкурентный рынок.
Появляется возможность выбрать и передать в разработку то, что нужно реализовать в первую очередь, и с таким минимальным продуктом протестировать реакцию рынка, собрать обратную связь от клиентов. Тот функционал, который можно разрабатывать во вторую и последующие очереди, можно реализовывать за пределами этого минимального продукта, выводимого на рынок первоначально.
Независимый проектировщик поможет и здесь, поскольку не будет убеждать заказчика, что функционал необходимо реализовать непременно полностью. У проектировщика (если он не часть исполнителя-разработчика) нет стимула продавать часы разработки.
Как лучше всего проверить, насколько созданное решение соответствует проекту, а также качество этого решения? Существует два способа. Первый: можно возложить контроль качества на проектировщика, если он принимает участие в управлении проектом. Второй способ: можно нанять третьего участника «со стороны», который приведёт контроль качества создаваемого ПО независимо и от проектировщика, и от исполнителя-разработчика. Десятилетиями эксплуатируемый во всех отраслях механизм независимой приемки отлично работает и при реализации проектов создания ПО.
Цена
Если заказчик принимает решение о разделении ролей в проекте, применении практик проектного управления, которые известны человечеству много десятилетий и с помощью которых строятся мосты, здания и атомные электростанции, то менеджмент заказчика принимает на себя ответственность за выбор направления, ход реализации, сроки и успешность завершения проекта создания программного обеспечения. Менеджмент заказчика в определенной степени теряет возможность переложить ответственность на единого исполнителя по проекту в рамках своей внутрикорпоративной политики. Не в последнюю очередь поэтому наша компания видит своими клиентами скорее малые и средние бизнесы, для которых очень важна реальная возможность кратно снизить бюджет на разработку ПО.
