Мы привыкли считать, что IT проект — это проанализируй работу заказчика, собери требования, спроектируй продукт, нарисуй продукт, запрограммируй, протестируй, передай заказчику. Именно поэтому, измерять успешность и опытность менеджера проектов, аналитика, программиста, тестировщика, архитектора мы привыкли количеством завершенных проектов. Но насколько это правильно? Допустим, приходит к вам на собеседование опытный менеджер проектов, который работал с десятками, а то и сотнями клиентов, но вот выясняется, что ни одного “закрытого проекта” у него нет. О чем это говорит? Он плохой менеджер? Не доводит дело до конца? Ни о чем это не говорит, тут надо разбираться гораздо глубже.
Термин Continuous development/deployment является относительно молодым, его стали использовать в начале 2000х и начали, в частности, с термина Continuous Integration (материал по ссылке). Разумеется, как и всегда, начали с технической части, но вскоре этот принцип перешел и на работу с клиентами, и управление проектами. Проекты по continuous development (или по-русски непрерывная разработка) стали особым трендом в Европе. Общаясь с одной из IT компаний, мы выяснили, что на волне популярности принципов Agile разработки (о ней мы еще расскажем в будущем более подробно), ориентации на постоянную коммуникацию и добавление ценности заказчику, Continuous development стал стилем работы с клиентом.
Компания-поставщик (IT компания) и компания-заказчик заключают контракт, в рамках которого компания-поставщик разрабатывает и внедряет самую базовую функциональность программного продукта, удовлетворяя наиболее критичные потребности заказчика. После чего, компании заключают партнерское соглашение по совместной работе и развитию информационно-технологической поддержки компании-заказчика на стратегическом уровне. Следует подчеркнуть, что под стратегическим уровнем здесь понимается не просто ежедневное судорожное допиливание функциональности в имеющемся программном продукте, но совместный анализ возможностей компании на рынке и разработка информационно-технологической поддержки для роста и достижения стратегических целей. Ведь давайте не будем забывать, что IT — это, прежде всего, инструмент для ведения бизнеса, но никак не самоцель. Описанный подход и получил (пока не окончательно) название Continuous development, и являет собой, по сути, Agile подход не просто к разработке software, но вплоть до работы с клиентом, а в его основе лежат:
- постоянная коммуникация с заказчиком,
- заинтересованность в его успешном ведении бизнеса,
- постоянную доставку новой функциональности.
Чтобы не быть голословными, приведем простые примеры компаний, занимающихся Continuous development: Facebook, Amazon, Airbnb и другие. Конечно, это компании сектора B2C, здесь немного проще заниматься постоянным совершенствованием и обновлением софта, тем более если софт, по сути, и является твоим основным сервисом. В отношениях B2B все немного сложнее с финансовой и юридической точек зрения при использовании такого подхода, но и в этом секторе есть такие компании. Ну а теперь, возвращаясь к нашему примеру с менеджером проекта на собеседовании. В связи с тем, что мы обсудили выше, следует обратить внимание на то, сколько его проектов являются проектами по Continuous development или перешли в этот класс проектов после базового внедрения. Заключение такого контракта с компанией-заказчиком является сложнейшей задачей для компании-поставщика, ведь она требует не только высокой степени профессионализма команды разработчиков (как с технической, так и с бизнес точек зрения), но также и высокого уровня доверия между компаниями. Именно поэтому количество “завершенных” проектов сегодня — не такой уж и объективный показатель, гораздо важнее сегодня — это количество и уровень текущих клиентов.
