ИТ-Стайер

Глава 13
Немного о внутрикорпоративных проектах

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

Например, проект “Автозаказ”. Мы хотим, чтобы информационная система самостоятельно рассчитывала количество товара к заказу, на основании данных о продажах, остатках и некоторой другой информации. Многие ошибочно думают, что самое сложное здесь алгоритм. Алгоритмы расчета давно не являются секретом, их можно найти массу, а также придумать и реализовать свои, но это будет, наверное, не более 20% от того, что нужно сделать. Нужно учесть еще массу параметров, а для этого требуется наладить их внесение, сбор, проверку корректности, учет всяких хитрых условий и ситуаций. Графики доставки, активный ассортимент, доступное полочное пространство, промоактивность и пр.пр.пр. Короче обвес алгоритма намного сложнее и более трудоемок, чем работы по программированию самого алгоритма. А потом еще есть огромный объем работ, по внесению необходимых параметров и всяким настройкам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочитав книгу про SCRUM Джеффа Сазерленда, я нашел реально много общего с той организацией работ, которой мы придерживались.

Ежедневные обсуждения хода работ при обходах – это те же scrum-meeting, еженедельные совещание – это тоже планирование спринтов. Да, мы не развлекались досками и оценкой производительности, но в условиях внутрикорпоративной разработки – это не факт что является необходимым.

Гибкость и адаптивность ИТ – это то, что может адекватно поддержать проектную деятельность внутри компании в условиях нехватки ресурсов и зачастую факультативного подхода к проектам бизнес-подразделений.

У Эрика Риса в книге “Бизнес с нуля” я почерпнул очень интересную мысль (эту книгу полезно прочитать всем руководителям, а ИТ-шным тем более). Внутрикорпоративные проекты – это в большинстве своем стартапы. И для управления ими стоит применять соответствующие методики.

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

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

Глава 14
Про бег

– Работать нужно не 12 часов, а головой!

Стив Джобс

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

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

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

Стив Джобс любил “бегать”. Он выходил на старт и в гараже, собирая первый “Макинтош” и в офисе огромной корпорации, планируя запуск очередного яблочного продукта.

У каждого из нас свои дистанции и свои приоритеты. Кто-то всю жизнь бегает по кругу домашнего стадиона, кто-то занимается кроссом и предпочитает пересеченную местность, кто-то ждет очередного марафона или убийственного испытания а-ля IRONMAN, ну а кто-то предпочитает наблюдать за всем этим с дивана.

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

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

Тренировки позволят вам быть всегда в хорошей форме. Читайте, изучайте, следите за технологическими новинками, повышайте свой профессиональный уровень. Как только вы перестанете тренироваться – вы начнете отставать. Мир ИТ очень быстро меняется. В реальном беге NIke придумала кроссовки, дающие прирост 5% к результату. Их правда сразу запретили, но в мире технологий таких запретов ожидать не приходится.

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

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

ИТ-сфера интересна тем, что она на прикладном уровне соприкасается уже практически со всеми сторонами жизни. Чем больше ваш кругозор, шире эрудиция, тем сильнее ваш потенциал и перспектива проявить себя.

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

– Хочешь быть красивым – бегай!

– Хочешь быть сильным – бегай!

– Хочешь быть умным – бегай!

Прошло немногим чуть более 30 лет и я стал подозревать, что в его словах есть определенный философский смысл.