Любой продукт можно улучшать до бесконечности. Всегда можно добавить содержание, а это повлечет изменение сроков. Любимая тема заказчика, это маскировать изменение изначально запрошенной функциональности словом “ошибка”. “Нам вот сейчас поправят ошибку” – только умалчивается, что имеет место не ошибка разработки, а ошибка постановки, которую допустил сам заказчик, упустив некоторые, оказавшиеся существенными детали. Если возникающие новые хотелки влияют на сроки, то Заказчик об это должен знать и это должно быть зафиксировано.
Вообще техническое задание вещь необходимая, но только для начала, так сказать “для затравочки”. Я практически не встречал случаев, когда внутрикорпоративная разработка, которая бы “взлетела”, была выполнена точно в соответствии с первичным ТЗ. В процессе работы меняется понимание, приходят новые идеи. Почему-то, казавшаяся вполне продуманной отрисованная экранная форма оказывается совершенно неудобной, когда ты начинаешь реально по ней тыкать мышкой.
Если настроен сделать хорошо, то стоит сразу быть готовым, что придется переделать несколько раз. Иногда даже проще сделать самому без оглядки на пользователя, потом показать и подстроить.
Когда я впервые столкнулся с AGILE, то был в какой-то мере сильно удивлен, поскольку оказалось, что интуитивно везде где я работал мы старались интегрировать эти принципы в культуру ИТ-подразделений и практически всегда это в большой степени удавалось. То, что кто-то озаботился сформулировать вызывает у меня аплодисменты. Стоит взять на вооружение.
Прочитав книгу про SCRUM Джеффа Сазерленда, я нашел реально много общего с той организацией работ, которой мы придерживались.
Ежедневные обсуждения хода работ при обходах – это те же scrum-meeting, еженедельные совещание – это тоже планирование спринтов. Да, мы не развлекались досками и оценкой производительности, но в условиях внутрикорпоративной разработки – это не факт что является необходимым.
Гибкость и адаптивность ИТ – это то, что может адекватно поддержать проектную деятельность внутри компании в условиях нехватки ресурсов и зачастую факультативного подхода к проектам бизнес-подразделений.
У Эрика Риса в книге “Бизнес с нуля” я почерпнул очень интересную мысль (эту книгу полезно прочитать всем руководителям, а ИТ-шным тем более). Внутрикорпоративные проекты – это в большинстве своем стартапы. И для управления ими стоит применять соответствующие методики.
Только нужно понимать, что внутрикорпоративные стартапы имеют свои серьезные особенности. Стабильная, и как правило, очень консервативная клиентская база, которую не нужно искать, но с которой нужно работать. Инвестор, которого не интересует твой цикл “создавать – оценить – научиться”, пугают и расстраивают твои “виражи”, и который не видит в том, что ты делаешь, бизнеса. И одно из главных – это то, что роль основателя стартапа очень размытая, непонятно кому принадлежащая, и функционально урезанная.
