ИТ-Стайер | страница 49



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

Давайте понимать, что если у вас не ИТ-компания, то у вас попросту практически не может быть чисто ИТ-шных проектов. ИТ-шники практически не бывают заказчиками и лучше их не делать руководителями проектов. Исключения пожалуй составляют только проекты связанные с какой-нибудь оптимизацией, реинжинирингом ПО, обустройству внутренних процессов ИТ, которые по большому счету никому кроме посвященных не видны.

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

Любой проект – это триада: содержание, сроки, стоимость.

Когда мы ведем внутреннюю разработку, то вопрос стоимости, к сожалению, зачастую просто опускается. Хотя было бы правильно, как минимум зарплату, занятых в проекте специалистов ИТ – учитывать в бюджете проекта. Иногда, если это делать, то проекты как-то отпадают. Когда озвучиваешь, что делать будем полгода и обойдется это компании примерно в восемь миллионов рублей, то у некоторых наступает момент отрезвления. Кто-то пытается поискать подешевле на рынке, но по моей практике быстро убеждается, что его хотелки по рынку стоят минимум в два, а то и в 3 раза дороже и вообще подобного готового почему-то нет.

Но обычной практикой является то, что ресурс внутренней разработки считается условно бесплатным. Руководство не задает вопросы сколько это будет стоить. Оно задает один вопрос: когда? Этот вопрос для него удобен, потому что его можно легко проконтролировать. Сделал запись и проверяй. А еще лучше: нарисуй мне какую-нибудь диаграмму Ганта и отчитывайся регулярно по ней.

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