Самое интересное, что ИТ-шников постоянно пытаются сделать ответственными за подобного рода проекты в целом и именно им начинают задавать вопросы “а как там?”. Они уверенно отвечают “у нас все хорошо”, подразумевая, что они выполнили все основные технические задания. А потом приходят недовольные люди из бизнеса и говорят, что “не все хорошо”, а стоило бы еще сделать это и это. При этом зачастую они забывают сказать, что они пока сами не знают как это сделать и поможет ли это реально и вообще они просто не организовали процесс настройки и внесения необходимых данных.
Давайте понимать, что если у вас не ИТ-компания, то у вас попросту практически не может быть чисто ИТ-шных проектов. ИТ-шники практически не бывают заказчиками и лучше их не делать руководителями проектов. Исключения пожалуй составляют только проекты связанные с какой-нибудь оптимизацией, реинжинирингом ПО, обустройству внутренних процессов ИТ, которые по большому счету никому кроме посвященных не видны.
Все основные проекты – это проекты бизнеса и отвечать за них должен бизнес. Никто не снимает с ИТ-шников ответственности за их часть, но в целом их роль вспомогательная.
Любой проект – это триада: содержание, сроки, стоимость.
Когда мы ведем внутреннюю разработку, то вопрос стоимости, к сожалению, зачастую просто опускается. Хотя было бы правильно, как минимум зарплату, занятых в проекте специалистов ИТ – учитывать в бюджете проекта. Иногда, если это делать, то проекты как-то отпадают. Когда озвучиваешь, что делать будем полгода и обойдется это компании примерно в восемь миллионов рублей, то у некоторых наступает момент отрезвления. Кто-то пытается поискать подешевле на рынке, но по моей практике быстро убеждается, что его хотелки по рынку стоят минимум в два, а то и в 3 раза дороже и вообще подобного готового почему-то нет.
Но обычной практикой является то, что ресурс внутренней разработки считается условно бесплатным. Руководство не задает вопросы сколько это будет стоить. Оно задает один вопрос: когда? Этот вопрос для него удобен, потому что его можно легко проконтролировать. Сделал запись и проверяй. А еще лучше: нарисуй мне какую-нибудь диаграмму Ганта и отчитывайся регулярно по ней.
Вопрос “когда?” является крайне противным, потому что его начинают задавать, в то время когда мы еще практически не представляем себе ответа на вопрос “что?”. Мы не имеем четкого технического задания, мы еще не прорабатывали детали и не можем сказать сколько времени это займет точно. И люди, которые привыкли к некой достаточно конкретной системе координат, а ИТ-шники в основном относятся именно к этой категории, впадают в ступор. Они пытаются каким-то образом прийти к какому-то ответу с учетом массы неопределенных условий, предугадывая возможные варианты постановки, проблемные места и пр. Ответ получается примерно следующим: “Если все будет просто, то столько-то дней, а если вылезет вот это, то столько, а если случится это, то еще нужно будет приплюсовать ..”.
Такой ответ не вносит ясности и в большинстве случаев вызывает сугубо раздражение, которое приводит к взаимной неудовлетворенности и нарастанию напряжения.
Можно ли этого избежать? Можно. Стоит довериться своим ощущениям. Когда я проходил свое становление, как ИТ-директор в Магните, именно на такой термин навел меня Галицкий. “Не пытайся высчитать точно. Скажи когда будет готово по твоим ощущениям”. Наша нейронная сеть, называемая мозгом, с набором опыта начинает выдавать поразительно точные ответы. Плюс-минус неделя – это тот интервал, который вполне приемлем для внутрикорпоративной разработки.
Со временем ты начинаешь чувствовать заказчиков и предполагать, что от них можно ожидать в виде постановки и возникновения потом дополнительных хотелок, ты знаешь производительность своих сотрудников, ты вносишь допуски на непредвиденные ситуации в виде отрыва сотрудников на тушение пожаров, отпуска, болезни, и, в конце концов, достаточно корректный прогноз у тебя возникает как бы сам по себе. Раскидать его по конкретным этапам возможно, но большого смысла, как показывает практика, не имеет.
Вообще со сроками при внутрикорпоративной разработке все очень не просто. Можно всегда успевать по срокам, но будет ли от этого хорошо? Многие проповедуют принцип: дайте мне ТЗ, я назову сроки и точно по ТЗ я выполню все в срок. Мой опыт показывает, что такой подход ни к чему хорошему не приводит. Во внутрикорпоративной разработке жесткое соблюдение сроков по большому счету требуется ну в очень ограниченных случаях, например, когда требуется выполнить некие требования введенные государством. В таком случае мы ставим срок во главу угла и стараемся его выполнить всеми возможными способами, жертвуя удобством пользователей, эргономикой, производительностью – всем чем можно – лишь бы успеть. Но в большинстве случаев плюс-минус месяц не является таким уж критичным: “как-то до этого же жили”.