Большинство ИТ-проектов, которые я видел в жизни, были очень успешными. Выполнялись они в разных компаниях, на всевозможных платформах, совершенно разными людьми. Но успех приходил всегда, за редкими исключениями.
Я каждый раз удивлялся, откуда у ИТ-команд такая целеустремленность, тонкое чувство стратегии и ее реализации, понимание ситуации и железная воля следовать избранным путём? Есть ли какой-то секрет успеха?
Я посмотрел, проанализировал, и составил перечень алгоритмов, которые успешно приводят ИТ-проекты к цели. Начнем с целей — чего же такого успешно достигается?
Внимание. Эта статья — только для людей из мира ИТ. Если вы не из ИТ, или, не дай Бог, какой-нибудь директор или собственник, вам лучше не читать эту статью. Иначе вы всё нам испортите.
И еще раз внимание. Эта статья — не сарказм, не попытка кого-то разгромить, не градация рынка и не поднятие чьего-либо ЧСВ, включая моё. Я, как и любой ИТ-специалист, и компания, в которой я работаю, как и любая другая ИТ-компания, подходят под определения из этой статьи.
Цели
Попробую прояснить цели ИТ-проектов. Не вымышленные, объявленные в бумагах, на митингах или в богато обставленных кабинетах генералов. Настоящие цели.
Цель, ее осознание и понимание, имеют первостепенное значение в любой деятельности. И здесь не важно, хороша или плоха истинная цель в системе ценностей. Если объявлена одна цель, а в реальности, или даже в подсознании, сидит другая, то именно другая и будет достигнута.
Но, к сожалению, в отношениях ИТ и бизнеса устоялся неправильный стереотип. Считается, что большинство ИТ-проектов — провальные. Какие-то аналитики собирают статистику, чего-то высчитывают, потом пишут разгромные статьи о том, как ИТ не помогает бизнесу, не достигает поставленных целей, плодит суррогаты, отнимая у несчастных компаний миллионы в любой валюте.
Ошибка этих аналитиков очень проста: они судят со стороны бизнеса. Автоматизируемого, а не автоматизирующего. Оценивают проекты не в той системе координат, в которой они выполнялись. Смотрят на достижение целей, которые кто-то, когда-то, в самом начале, зачем-то сказал или написал. А про настоящие цели вообще не знают.
Настоящих целей ИТ-проектов, если обобщить, бывает четыре:
1. Подсадить;
2. Зацементировать;
3. Выжать;
4. Поучиться.
Подсадить на себя
Подсадить — это все проекты по внедрению 1С. Сюда же — автоматизация на любом слабо распространенном фреймворке или ПО. Сюда же — говнокод, «в котором только я разберусь».
Внедрив 1С, клиент всегда подсаживается на т.н. «Информационно-технологическое сопровождение». По-русски это абонентская плата за доступ к обновлениям. Необходимость обновлений оспаривать бессмысленно — её подкидывает государство. НДС 20%, разного рода ФЗ, онлайн-кассы, ЕГАИС и т.д. — все это отражается в программах 1С и, следовательно, надо обновляться.
Аналогично — битрикс. Кто бы не построил на нём сайт, надо платить за обновления и наличие тех.поддержки.
Аналогично — любой онлайн-сервис, будь то электронный документооборот, карты, сверка взаиморасчетов или проверка контрагентов. Большинство из них требуют некоторых работ по встраиванию в корпоративную систему и, чем больше денег и усилий на это потрачено, тем сложнее будет отказаться.
Время, в течение которого клиент подсажен, работает против него и на успех продавца ПО или услуг. Даже если берут только обновления, без доработок на заказ, выплаченная сумма с каждым месяцев растёт, и отказ от ПО или сервиса будет означать, что деньги выброшены на ветер.
Цель простая — сделать так, чтобы клиент, единожды поработав с вами, пусть даже по небольшой задаче, никогда не соскочил, и продолжал заказывать новые продукты и услуги именно у вас.
При правильном подходе работает лучше, чем у драгдилеров — там хоть можно «поставщика» сменить, товар-то один и тот же. Но если вы написали клиенту, например, «оптимизированную выгрузку товаров на сайт», да про обфускацию не забыли, и использовали какие-нибудь хитровыдуманные константы, установленные только в этой конкретной БД, то клиент — ваш.
Важно, как говорится, влезть. Зацепиться, хотя бы за краешек.
Подсадить — пожалуй, самая распространенная цель ИТ-проектов.
Зацементировать
Зацементировать — это любимая цель внутренней автоматизации. Отличие заводских программистов, или фикси, в том, что они не получают дохода от выполнения проектов. Бывают, конечно, премии, но если их размазать по году, то получится мизер. Оклад намного проще и стабильнее, к тому же всегда есть возможность подработок.
Заводской программист мыслит, как солдат, который спит, а служба идет. Поэтому естественным стремлением является повышение эффективности своего рабочего дня. Помните, что такое эффективность? Это затраты на производство результата.
Результат один и тот же — оклад. Затраты — это усилия. Оклад повысить нельзя, а усилия сократить — можно. Так и повышается эффективность.
Простейший путь — говнокод, «максимально отражающий требования пользователей». Под говнокодом здесь имеются в виду и сам код, и метаданные, и «кнопочка вот тут». Никакого анализа требований, соответствия общей архитектуре и стратегии, «лишь бы работало».
Когда «работает» — это цемент. То, что «работает», все боятся трогать — и программисты, и пользователи, и руководители. Любой революционер, который начнёт вопить «нам нужен рефакторинг», будет изгнан, опозорен, унижен, обвинен в желании повыделываться и испортить бизнесу жизни.
Если «работает» — все хорошо и программист молодец. Он продолжает получать свой оклад. Чем больше областей в информационной системе, которые «работают», тем меньше у программиста работы. Остается только поддержка — ответы на одни и те же вопросы, демонстрация одних и тех же форм и инструментов, решение одних и тех же проблем. Просто и стабильно, как у солдата.
Цементированием не брезгуют и проекты автоматизации силами внешнего подрядчика, особенно под конец. Например, надо акт подписать. Два месяца делали «как положено», но директор из центра требует денег, иначе перестанет платить зарплату. Надо срочно сделать так, чтобы клиент был доволен. Как? Зацементировать, как заводские программисты. Говнокодом.
Выжать
Выжать — это цель, как правило, для неуверенных в себе. Например, есть небольшая шаражка по внедрению 1С. Перебивается мелкими работами по обновлениям и печатным формам, продажей дешевых коробок, пожарными консультациями ларьков во время сдачи отчетности.
И тут — бац, счастье привалило. Проект. Невесть откуда, вероятно — по ошибке, шаражке доверяют внедрить большое и серьезное решение. Что делать? Опыта нет, специалистов — тоже.
Стараются тупо урвать по максимуму. Оплата — по часам, или короткими актами, не больше месяца. Никакой привязки оплаты к целям, бизнес-показателям, завершенности и тому подобной ереси. Минимум рисков, максимум денег.
Аналогично поступают специалисты, которые не специалисты, но попали на работу в приличное место — например, с высоким окладом. Они стараются надувать щёки, не выдавать своей некомпетентности, никогда не углубляются в детали, все время откладывают принятие решений и начало работ.
Например, в одной из компаний взяли ИТ-директором человека, в глаза не видевшего 1С. А взяли для решения конкретной задачи — внедрения 1С. На собеседовании сумел пустить пыль в глаза, его взяли на приличный оклад, и он продержался год. Только когда к стенке припёрли — признался, что не знает 1С. Просто уволился, и пошёл искать следующую компанию, которую можно выжать.
Поучиться
Редко, но такое бывает. Молодая компания хочет ворваться на рынок ERP-систем. Или старая компания хочет развить новое направление. Или вообще стратегия такая — обучать новых специалистов, бросая их в самое пекло.
Звучит-то красиво — бросать в пекло. Вроде известной притчи о том, как учить плавать, бросая в воду. Но на деле, если не врать себе, мы просто обучаем своих специалистов за деньги заказчика.
Чего греха таить — я сам бывал в подобной ситуации. Прошел лишь месяц с тех пор, как я впервые увидел в глаза 1С, и вот я уже на проекте по внедрению самой сложной (на тот момент) конфигурации — «Управление производственным предприятием». Просто потому, что продукт — новый, только появился, и проект по его внедрению у компании — первый. Мало того, он и в городе — первый, а может и в регионе.
Я, конечно, многому научился на том проекте. А заказчик всё это оплатил. Достаточно было руководителю проекта на совещании, где меня представляли, утвердительно кивнуть в ответ на вопрос «а он восьмёрку-то знает?».
Я нисколько не осуждаю такой подход — тем более, что сам им часто пользовался, и продолжаю практиковать. Заказчик, как правило, в душе не знает, какой специалист в чём разбирается. Стоимость часа работ — одинаковая, и для новичка, и для зубра. Новичок будет делать неделю, зубр — два часа. Заказчик оплатит неделю. Что не так?
Бывают и другие проекты с целью поучиться. Например, внедрение нового, только что разработанного продукта. Бывает и так, что заказчик получает этот продукт бесплатно. Может, даже и услуги по внедрению, или их часть. Я сам таким подходом пользуюсь. Бесплатность хороша — она избавляет от рисков.
Комбинации и трансформации
Цели проекта могут меняться в процессе его реализации, в зависимости от ситуации. Это нормальный, живой процесс.
Выше я приводил пример, как проект с целью подсадить может начать цементироваться — когда надо подписать акт. Обычно это происходит, когда нависает угроза срыва проекта.
Однако, не обязательно именно цементировать, можно и выжать. Например, ситуация — при внедрении начато сразу несколько этапов. Где-то идет обучение, где-то тестирование, где-то тестовая эксплуатация. И вот появилась общая угроза срыва проекта — мало ли, ЛПР поменялся.
Часть этапов можно зацементировать, если это возможно. Цементирование, скорее всего, позволит получить всю сумму за этап проекта. Но бывает, что этап находится только на стадии разработки, пусть и в шаге от продакшн — тогда до цементирования еще далеко, заказчик даже прототипа не видел. Как вариант, можно попробовать выжать — подписать акт на часть суммы. Допустим, только за разработку, прибавив фразу «за уже фактически потраченное время».
Бывает и обратная трансформация — начинали как «выжать», по ходу разобрались, и делаем «подсадить на себя». Или так зацементировали, что впору выжать остатки и бежать.
Теперь, зная эти цели, посмотрите на ИТ-проекты, которые вы видели. Достигли ли они хоть одной из них?
Резюме
Хотите верьте, хотите нет, но статья родилась спонтанно. Я сел написать текст о том, как влияет множество интеграций на сложность изменений в бизнесе.
А потом подумал — чего сопли-то жевать? Опять из пальца высасывать какую-то пользу для несчастных заказчиков, и как мы, ИТ, его этой пользы лишаем? Не лучше ли заняться реальностью?
Реальность — это тысячи внедрений информационных систем, разработанных сайтов, подключенных сервисов и развёрнутого парка оборудования.
Да, в большинстве случаев заказчик ноет, что ИТ-проект не достиг каких-то его целей.
Напоминает романтичную девушку, мечтающую о прогулках за руку с кавалером, по цветущим лугам, с венком из одуванчиков на голове, и чтоб солнышко светило ярко-ярко, а он такой в белоснежной рубашке навыпуск, улыбается, и ничего ему не надо, только быть со мной рядом, купаться в бездонном океане обаяния моей молодости, красоты и чистоты, и весь мир создан только для меня, и Он — тоже, для меня…
Нет, милая моя. У Него — другая цель. И ты знаешь, какая. Он своей цели достигнет. Если не с тобой, то с другой. И не раз.
Зачем фантазировать, если есть реальность? Да, бывают проекты, повышающие эффективность заказчиков. Да, у клиентов и прибыль может вырасти — или за счет роста дохода, или через сокращение затрат. Но большинство ИТ-проектов — чтобы подсадить, или зацементировать, или выжать, или поучиться.
Так чего фантазировать, пенять на несправедливость, призывать изменить и измениться, верить в добро и сказки? Лучше разобраться, как больше подсаживать, меньше цементировать, вообще не выжимать и в процессе учиться.
Этим и предлагаю заняться. Если не возражаете.
