ИТ-Стайер

Вопрос “когда?” является крайне противным, потому что его начинают задавать, в то время когда мы еще практически не представляем себе ответа на вопрос “что?”. Мы не имеем четкого технического задания, мы еще не прорабатывали детали и не можем сказать сколько времени это займет точно. И люди, которые привыкли к некой достаточно конкретной системе координат, а ИТ-шники в основном относятся именно к этой категории, впадают в ступор. Они пытаются каким-то образом прийти к какому-то ответу с учетом массы неопределенных условий, предугадывая возможные варианты постановки, проблемные места и пр. Ответ получается примерно следующим: “Если все будет просто, то столько-то дней, а если вылезет вот это, то столько, а если случится это, то еще нужно будет приплюсовать ..”.

Такой ответ не вносит ясности и в большинстве случаев вызывает сугубо раздражение, которое приводит к взаимной неудовлетворенности и нарастанию напряжения.

Можно ли этого избежать? Можно. Стоит довериться своим ощущениям. Когда я проходил свое становление, как ИТ-директор в Магните, именно на такой термин навел меня Галицкий. “Не пытайся высчитать точно. Скажи когда будет готово по твоим ощущениям”. Наша нейронная сеть, называемая мозгом, с набором опыта начинает выдавать поразительно точные ответы. Плюс-минус неделя – это тот интервал, который вполне приемлем для внутрикорпоративной разработки.

Со временем ты начинаешь чувствовать заказчиков и предполагать, что от них можно ожидать в виде постановки и возникновения потом дополнительных хотелок, ты знаешь производительность своих сотрудников, ты вносишь допуски на непредвиденные ситуации в виде отрыва сотрудников на тушение пожаров, отпуска, болезни, и, в конце концов, достаточно корректный прогноз у тебя возникает как бы сам по себе. Раскидать его по конкретным этапам возможно, но большого смысла, как показывает практика, не имеет.

Вообще со сроками при внутрикорпоративной разработке все очень не просто. Можно всегда успевать по срокам, но будет ли от этого хорошо? Многие проповедуют принцип: дайте мне ТЗ, я назову сроки и точно по ТЗ я выполню все в срок. Мой опыт показывает, что такой подход ни к чему хорошему не приводит. Во внутрикорпоративной разработке жесткое соблюдение сроков по большому счету требуется ну в очень ограниченных случаях, например, когда требуется выполнить некие требования введенные государством. В таком случае мы ставим срок во главу угла и стараемся его выполнить всеми возможными способами, жертвуя удобством пользователей, эргономикой, производительностью – всем чем можно – лишь бы успеть. Но в большинстве случаев плюс-минус месяц не является таким уж критичным: “как-то до этого же жили”.

Сроки нужны больше для себя. Помните осликов, которые любят бегать и не должны заплывать жиром? Поверьте, ИТ-шники очень любят передавать свой труд в эксплуатацию. Никто не стремится затягивать. В основном сдвиги сроков связаны либо с тем, что была изначально неправильно сформулирована или понята задача, либо с желанием что-то улучшить, либо с дополнительными функциональными хотелками, либо с какими-то реальными техническими трудностями.

Итого. На вопрос о сроках стоит отвечать уверенно и конкретно. Как правило, не нужна конкретная дата. Достаточно недели. Правда нужно быть готовым, что тебе зададут вопрос: а почему столько? Это, кстати, был любимый прием Галицкого, когда он начинал тебя пробивать на предмет того, можно ли их сократить. Только у меня есть ощущение, что настоящая цель крылась немного в другом. Подозреваю, что истинной целью Сергея Николаевича было ввести менеджера в тонус, прощупать его погруженность и дать определенный эмоциональный заряд.

Любой продукт можно улучшать до бесконечности. Всегда можно добавить содержание, а это повлечет изменение сроков. Любимая тема заказчика, это маскировать изменение изначально запрошенной функциональности словом “ошибка”. “Нам вот сейчас поправят ошибку” – только умалчивается, что имеет место не ошибка разработки, а ошибка постановки, которую допустил сам заказчик, упустив некоторые, оказавшиеся существенными детали. Если возникающие новые хотелки влияют на сроки, то Заказчик об это должен знать и это должно быть зафиксировано.

Вообще техническое задание вещь необходимая, но только для начала, так сказать “для затравочки”. Я практически не встречал случаев, когда внутрикорпоративная разработка, которая бы “взлетела”, была выполнена точно в соответствии с первичным ТЗ. В процессе работы меняется понимание, приходят новые идеи. Почему-то, казавшаяся вполне продуманной отрисованная экранная форма оказывается совершенно неудобной, когда ты начинаешь реально по ней тыкать мышкой.

Если настроен сделать хорошо, то стоит сразу быть готовым, что придется переделать несколько раз. Иногда даже проще сделать самому без оглядки на пользователя, потом показать и подстроить.