Иду на цель
(о целях бизнеса и программистов)

Программисты - волшебники: они создают программы, 
осязаемые, ощущаемые, видимые - из чистой, невесомой мысли*

Помните книжных волшебников, таких, как примеру как Гарри Поттер, или, если вам ближе Старик Хоттабыч и множество других книжных персонажей. Одним своим словом, они создавали материальные вещи и вызывали природные катаклизмы, заставляли летать по воздуху себя и других, да и много чего еще. Хотя Старик Хоттабыч, по моему ничего слишком страшного не делал. Ну, отправил всех людей из цирка неизвестно куда, но ведь вернул же обратно их в нашу жизнь цирк, но делал это одной лишь силой мысли, и что интересно, произносил он при этом одни и те же слова, не в пример всем этим зарубежным доморощенным волшебникам.

Вот и программисты туда же - волшебники. Если допустить их к бизнесу, то они устроят небольшой микровселенский катаклизм в отдельно взятой компании максимально возможный из того, на что им хватит сил и умений. При этом они часто не действуют по одиночке, они собираются в большие и не очень стаи фирмы и делают свое дело в том масштабе, до которого могут дотянуться. Они рыщут по городам с одной лишь мыслью, где найти того человека (фирму), который поверит в их волшебные способности и скажет им, «а сотвори-ка мне чудо» и тогда джин из бутылки будет выпущен…

К чему это я? А к тому, что в большинстве случаев в бизнесе не нужны чудеса, в этом нет необходимости. Бизнес либо работает, либо умирает, и никакое программистское чудо не сможет переломить второй вариант, если на это есть объективные причины. Как говорят, есть компании быстрые и мертвые. При этом работающий бизнес также можно «завалить» непомерными расходами на IT. Но вот мертвый бизнес реанимировать при помощи IT – невозможно (кстати, можно повысить капитализацию умирающего бизнеса при помощи покупки какой-нибудь системы автоматизации, а затем попытаться продать его).

Итак, обратимся к одной из многих проблем, которые возникают в процессе взаимодействия разработчиков и заказчиков этих самых программ. Это проблема конечных целей. Какая конечная цель у программиста? Об этом писал еще Брукс в своей книге «Мифический человеко-месяц или как создаются программные системы». В большинстве случаев программист получает удовольствие от самого процесса творения чудес «из чистой и невесомой мысли», когда из под его пальцев выходит такая программа как ОН хочет, со всеми завитками и финтифлюшками какие ему захотелось сделать.

Глаза программиста горят, хочется поделиться со всем миром своими достижениями. «Посмотрите, какую штуку я сделал, а как я алгоритм завернул, а вот я какой!» И тут же его полет обрывается шлепком в рыхлый глинозем действительности. «Что заказывали? Что делал две недели? Вот, что заказывали, то и делал, знаю, что сдача проекта, и не нужно так громко ругаться, успею, ладно, ладно уже иду доделывать».
Вот поэтому к простому программисту в более или менее крупных софтверных конторах далеко не бесплатным приложением идет ведущий программист и руководитель проекта, цели которых уже другие. Для ведущего программиста чистое программирование является только одной из целей, которой ему уже не дают заниматься так плотно, как раньше, когда он будучи простым «программером» мог не беспокоиться о том, что делают его соседи по офисному кубику.

А для руководителя проекта уже совсем не интересна «чистая мысль», он не получает от этого кайфа. Его драйв – управление. Ему нужна конкретная работа, которая продвинет проект еще на шаг к благополучной сдаче заказчику. Сдача заказчику – это хорошо, а затягивание сроков – это плохо. Вот здесь мы и подходим к главной проблеме. Проблеме нестыковке целей заказчика и разработчиков.

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

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

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

У наемного работника личные цели могут быть более простыми. Он глубоко не вникает: «Мне сказали найти программистов – я ищу. Мне сказали выбрать подешевле – я выбираю, а там пусть директор решает». И пока владелец (директор) не объяснит цели, которые он собирается достичь, работа может идти совсем в отличном от его директорского понимании направлении.

Теперь подумаем, как достичь взаимопонимания. Будем считать, что директор хочет получить дополнительные рычаги управления, а разработчик хочет получить завершенный проект (не будем принимать в расчет желание «волшебников» с их желанием запрограмировать что-нибудь ради удовольствия, они сами найдут время для удовлетворения своих амбиций).

Вот здесь и кроется большой подводный камень, или даже подводная скала, о которую как в Бермудском треугольнике может разбиться проект. (Или в Бермудском треугольнике были только саргасы, в общем, не важно). Проверить рычаг управления, можно только подключив его к управляемому устройству. Нужно соединить каждый винтик и болтик с нужными агрегатами, подключить датчики, дисплеи и табло на переднюю панель этого агрегата. При этом это уже работающий агрегат. Никто не собирается останавливать бизнес. Представьте, что на идущий на полном ходу грузовик, кто-то станет привинчивать новый супер-современный штурвал вместо старого доброго руля. Или менять на ходу ручную коробку передач на автоматическую. В бизнесе все происходит именно так. Старый руль продолжает работать некоторое время, пока сотрудники привыкают к работе с новым. И только через какое-то время (на практике где-то в районе полугода для проектов до 10-15 пользователей) старый руль окончательно демонтируют, ручку старой коробки передач выкинут и полностью перейдут на электронное управление. (Так и хочется сказать: и жили они счастливо и умерли в один день! Вместе со своей электронной коробкой.)

Но до этого момента. Директор не может даже проверить, как действуют эти рычаги управления. Может быть они самые лучшие, может быть их ставили уже на столько грузовиков, сколько ему и не снилось. Но вот он ходит и смотрит на эти лежащие на прилавке электронные штучки. Как это будет работать на его машине бизнесе… Думает он, почесывая лысеющую от постоянных забот голову, «а была не была. Нужно пробовать!».

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

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

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

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

Сначала директор доверяет тому, что делают приглашенные специалисты, затем в один непрекрасный момент у него заканчивается терпение или приходит очень начитанный системный администратор, который, глядя на то, что разработчики делают, морщит лоб и шепчет директору, «да что это такое. Что они делают, это же все неправильно». Зерна сомнений заронили, и, в конце концов они дадут колючие всходы, особенно, если системный администратор будет усердно продвигать свои цели. А у него совсем другие цели, обычно они заключаются в том, чтобы ЕМУ (администратору) программисты не мешали работать и не ставили на ЕГО сервер, который он так холил и лелеял никаких новых программ. К предыдущим целям добавилась новая и, как лебедь рак и щука воз непонятно куда тянется. Если руководитель не разрулит ситуацию, то воз так и останется на том самом месте, где его остановила тяжелая рука сомнений.

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

Определяйтесь с целями, господа!

*Вынесенная в эпиграф фраза взята из Э. Хант, Томас Д. Программист - прагматик. Лори - 2004, 288 стр.