**6.1. Некоторые мысли про ведение ИТ-проектов.

Привет.**

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

Контрольные точки самого менеджера:

1. Все ли необходимые вопросы я задал заказчику (подрядчику)? Детализировать список подобных вопросов смысла нет, у каждого человека (команды) он свой в силу их специфики. Важно, задаете ли и получаете ли вы на них ответы систематически, регулярно.
2. Проработал ли я те риски проекта, которые релевантны проектам именно в нашей сфере, индустрии, компании? Например: доступность команды заказчика (подрядчика) для совместной работы, знакомство сторон с используемым инструментарием, наличие опыта в похожих проектах.
3. Какие ключевые финансовые показатели проекта?
4. Какая загруженность у моей команды, есть ли пересекающиеся проекты и задачи, какие у них сроки?

Про построение команды и передачу компетенций.

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

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

При этом не надо пренебрегать опытом команды. Любую новомодную, самую эффективную практику следует адаптировать под реалии, ресурсы, сотрудников вашей команды/компании (если нет задачи поменять культуру самой организации).

Вопрос передачи знаний от старых сотрудников новым.

Существуют два подхода, которые зависят от двух факторов:

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

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

Скоро продолжим.