Глупые мысли об IT

Привет, народ!

В данной статье я хотел бы рассказать об ошибках, которые я когда-либо наблюдал при работоте над проектами. В некоторых ошибках была моя прямая вина, за другие я с радостью переложу ответственность на людей, которые были заняты со мной в различных проектах. Некоторые вещи были достаточно тривиальные и при правильном подходе можно было бы легко их избежать, другие проявлялись из-за системных проблем, таких как отсутствие взаимодействия между командами, работающими над разными задачами в проектах.
Немножко отвлекусь: все, что не делается/внедряется в IT, делается для кого-то. Очень тяжело найти проекты, которые начинаются и внедряются только ради самого IT. Кто-то, а это может быть или бизнес, на которого работает IT отдел, или клиент, который обратился в IT фирму разработать программу или решение, всегда получает напрямую или косвенно какие-либо результаты труда (и хочется верить – улучшения) IT отдела или поставщика. Поэтому к рассмотрению ошибок, сделанных при работе над проектам я предпочитаю подходить с этой точки зрения – с точки зрения выгоды, получаемой бизнесом или клиентом.
Если проект разделить на три фазы: начало проекта, внедрение и окончание, то каждая из фаз может иметь свои организационные (связанные с общим ходом проекта) и технические (техническое внедрение решения, выбор технологии и т.п.) проблемы. (Кстати, поймал себя на том, что мне тяжело использовать слово “проблемы”. В английском “problems” употребляется в смысле “проблем, которые очень трудно или невозможно решить”. Эквивалентом слова “проблемы” в английском является “issues” :))
В начале проекта самые большие ошибки, с которыми я сталкивался, были в основном организационные просчеты:

1. Начало работы над проектом без четких указаний от бизнеса: так называемых функциональных и не-функциональных требований (“Functional/Non-Functional Requirements (FRs/NFRs)”). Много распространяться на эту тему не буду, скажу только, что функциональные требования описывают что должно делать внедряемое решение, в то время как не-функциональные требования должны определять “как”, т.е. количественные и качественные характеристики. Если этих требований нет – это означает, что бизнес сам не понимает, что он хочет и можно потратить кучу времени и усилий на проект, который в конечном счете или “похоронят”, или потом  будет мучительно стыдно за результат работы :);
2. Не определены ясно и четко цели, область и бюджет проекта. В начале следует или получить от бизнеса, или самому “подвести за ручку” бизнес к составлению формального документа, который будет описывать: какие проблемы проект должен решить, какая будет выгода для бизнеса, сколько это займет времени и сколько это будет стоить. Это все, что нужно бизнесу знать! Бизнес не интересует какие модные технологии будут использоваться, как это будет сделано и т.д. Все, что интересует бизнес/клиента – “Сколько это будет стоить в деньгах и времени? И что мне с этого будет?”. Если ответы на эти вопросы будут кристально ясны – можно надеяться на поддержку проекта;
3. Не определены ключевые люди в проекте: заказчики (“stakeholders”); люди, в ответственность которых входит принимать решения по текущим вопросам, возникающих в ходе проекта в случае любых неточностей/конфликтов интересов (“accountable”); прямые исполнители (“responsible”), а так же те, кто более-менее заинтересован в успешном внедрении проекта и/или могут предоставить полезную информацию, которая может помочь с внедрением проекта (“informed” и “consulted”). Это могут быть рядовые сотрудники в бизнесе, которые знают в деталях области (использование программ, бизнес-процессы и т.п.), затрагиваемые в проекте.

Во время внедрения проекта самыми распространенными организационными ошибками были:

1. Ошибки в планировании необходимого количества ресуросов: инженеров в разных технических направлениях, менеджеров проектов и т.д.;
2. Недостаток знаний и умений у персонала, вовлеченного в проект. Были ситуации, когда решения “спускались  сверху” к выполнению, в то время как инженеры ни слухом ни духом не слышали о том, что надо делать и не имели опыта работы с требуемыми технологиями;
3. Отсутствие видимости прогресса и отчетности для заказчика. Вроде бы мелочь, но если проект сложный и растянут по времени, у заказчика может сложиться впечатление, что ничего не происходит. Опять же, многие технические специалисты в силу природной скромности :) не сообщают о каких-либо удачных решениях. Как показывает практика, умение играть в “политические игры” и представление в лучшем виде своих заслуг и достижений – лучшее средство для получения прибавки в зарплате и каръерном росте.

Нельзя сказать, что техническая сторона всегда была на высоте. Основными ошибками  были:

1. Использование технических решений, которые не соотвествуют требованиям. Это, скорее, результат подхода к проекту без понимания целей и требований бизнеса. Используется “модное” решение, которое вполне может не подходить по ряду причин в данный момент в данной ситации. Например, использование сервера баз данных Oracle вместо более дешевой и простой альтернативы из-за того, что Oracle “круче”. Без знаний и опыта работы с Oracle это может привести к проблемам вместо “летающей” баз данных;
2. Внедряемые решения конфликтуют с существующими IT сервисами. Вариантов - масса. Даже самый простой пример: использование серверной операционной системы, не поддерживаемой существующей системой создания резервных копий.  Что будет при возникновении непредвиденной ситуации, связанной с полной неработоспособностью сервера и невозможностью восстановить его с “ленты”!?
3. Внедряемые решения не согласуются со стратегией бизнеса. Это, конечно, более “туманное” определение проблемы, если коротко – то бизнес и IT двигаются в противоположных направлениях. Бизнес может постепенно “децентрализироваться”: переводить разные службы из центрального офиса в регионы, а IT служба не замечать этого и развивать IT сервисы для поддержки старой модели бизнеса. Может случиться, что после окончания проекта он будет никому не нужен именно из-за этого.

Ну а после окончания проекта возможна ситуация, когда проект не удовлетворяет бизнес или заказчика из-за:

1. Несоотвествие ожиданий бизнеса и результатов. Является следствием ошибок в начале проекта п.2 (“цели, область и бюджет”) и п.3 при внедрении (“отсутствие отчетности”). Вполне допустимо менять по ходу внедрения цели проекта, но любые изменения должны быть согласованы и подписаны с заказчиком;
2. Проект закончен, но с существенным превышением бюджета. Без соответствующей отчетности будет тяжело указать на причины превышения затрат, пусть даже они были и вызваны объективными причинами (бизнес мог  изменить требования, что привело к переделке, а следовательно, к удорожанию проекта);
3. Проект закончен с большой задержкой. Так же, как и в п.2, важно знать, чем это было вызвано.

В принципе, п.1-3 окончания проекта уже никак не исправишь. “Поздно пить боржоми…” :) Но при правильном подходе, при хорошей отчетности во время проекта, можно избежать больших споров с бизнесом/заказчиком по всем этим пунктам.
Напоследок хочу сказать: ни в коем случае нельзя соглашаться с бизнесом или заказчиком что-либо переделать в проекте без формального рассмотрения этого как изменения требований! Заказчик очень часто не понимает, что с “небольшие” изменения в проекте, особенно как результат “забывчивости” со стороны бизнеса о важной функциональности, могут вылиться в полную переделку решения. А это время, деньги и, что немаловажно, конечный результат и ожидания бизнеса. Если становится понятно, что количество мелких изменений переходит определенный порог или изменения могут привести к задержкам по срокам, цене – драться надо отчаянно и стоять до последнего! :) Пока бизнес/заказчик не подпишет документ об изменении в требованиях.
И совсем коротко, так как я планирую не накоторых вещах рассказать в следующих постах. Ничего нового изобретать не нужно, все уже давно изобретено: существуют много методик для ведения проектов (Prince2 и т.п.), методик разработки решений с технической точки зрения (TOGAF, Microsoft framework) и управления сервисами (ITIL).
Напоследок рекоммендую прочитать пост Алексея Глазкова “Правила работы надо проектом”.
Это все, что я могу сказать по поводу ошибок. Любые дополнения приветствуются :)

Засим раскланиваюсь,
Рустам.