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