10. Профессиональные направления практики 

На золотом крыльце сидели

Царь, царевич, король, королевич,

Сапожник, портной…

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

Разработчики

После 2го курса института, в 1991 году, проходя практику на предприятии, я осознал, что то, чему я учусь, является профессией «программист». В тот период был бум автоматизации хозяйственных и учетных операций предприятий. В задачу программиста входило:

1. Сбор требований от предметных специалистов,
2. Проектирование,
3. Разработка программы,
4. Установка программы на компьютере пользователя или сервере,
5. Обучение пользователей работе с программой,
6. Сопровождение. 

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

• проектирование
• разработка 

Консультанты

На одном из моих первых мест трудоустройства, я познакомился с компанией МетаТехнология и продуктом, который она распространяла – IDEF0. Этот продукт – был одним из первых кейс средств, позволяющих описывать бизнес процессы предприятий на языке IDEF0, семейства методологий IDEF. Спустя 6 лет, уже работая в Регибанке начальником отдела разработки и сопровождения программ, мне попалось описание методологии SADT, развитием которого, по сути, и была методология IDEF0. Прочитав его, я подумал, что было бы правильно перед разработкой программ, писать документы, в которых описывать автоматизируемые бизнес-процессы по данному стандарту. В тот момент уже можно было услышать слово «аналитик», но мы только начинали писать технические задания и это делали сами программисты. Еще через 3 года, в 2003 году я и сам устроился на работу в роли аналитика в питерскую компанию Рексофт. В проектах, в которых я участвовал в этой роли, моей задачей было писать технические задания для разработчиков и сдавать систему заказчику, помогать ему с внедрением системы.

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

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

• Понимание предметной области заказчика, сбор бизнес требований
• Определение и согласование рамок проекта
• Выработка бизнес решения
• Постановка задачи и передача информации разработчикам
• Внедрение системы у заказчика

 Системные инженеры

На наших первых проектах на платформе Documentum инсталляцию серверов и систем выполняли разработчики. Впервые мы попытались выделить роль специалиста по инфраструктуре в 2007 году. В проекте для компании Русгидро, который мы выполняли во время работы в КОРУС Консалтинг, Григорий Местечкин начал специализироваться исключительно на роли инженера. Его задачами были: развертывание инфраструктуры и решение проблем с системой, которые возникали на уровне инфраструктуры.

Позднее, работая в Синере и выполняя проект для Промсвязьбанка, мы привлекали к подобным задачам Александра Якимова – сотрудника компании Рексофт. Тогда же, в 2009 году, появилось понимание, что инженерные работы на проекте – это эпизодические работы, которые можно получать как сервис. Александр был из Санкт-Петербурга. К нам на проект в Москву он приехал всего пару раз для развертывания системы и решения технических проблем. Все остальные проектные задачи – сбор и формирование требований, разработка, внедрение, - не требовали постоянного наличия на проекте системного инженера. Однако и без этой роли ни один проект обойтись не может. Основные задачи данного направления являются:

• обеспечение инфраструктуры проекта
• установка релизов
• поиск и устранение проблем инфраструктуры

 Специалисты по тестированию (QA)

Впервые, информацию о том, что тестированием занимаются отдельно выделенные люди, я получил в 2004 году в компании Рексофт в нашем первом проекте по документообороту. Руководитель проекта – Айрат Файзрахманов, - спросил меня, когда и на какой период нам нужно забронировать в проект тестровщика. Моя реакция была : – А что так можно? Вот это здорово! До этого, проверкой возможностей системы, которую мы разрабатывали, и поиском ошибок занимались мы сами. Моя радость длилась недолго, так как тестировщик, не погруженный в функционал системы и не знакомый с платформой, мог найти только интерфейсные ошибки. А поскольку интерфейс системы писался на уже готовом фреймворке, то ошибок было найдено немного. Ошибки же логики, которые есть в каждой системе, тестировщику найти не удалось. Это обстоятельство привело меня к мысли, что тестированием должны заниматься консультанты, которые знают, как должна работать система, поскольку сами же этот функционал и описывали в техническом задании. Такого мнения я придерживался последующие лет 6, хотя меня продолжала беспокоить мысль, что это не самое эффективное решение – не зря же тестировщики существуют. Менять свою точку зрения я начал с 2010, когда на проекте в Промсвязьбанке, Дмитрий Шаповалов – наш архитектор и разработчик, - показал, что ему приходится тратить значительную часть своего времени на тестирование перед тем, как отдать релиз на проверку консультанту. Однако прошло еще год-полтора, прежде чем мне стала понятна основная разницу в ролях консультанта и тестировщика. Задача консультанта – мыслить так, чтобы проверить, что система работает, задача тестировщика – мыслить так, чтобы сломать систему.

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

 Инженеры технической поддержки

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

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

Службе технической поддержки нашей практики пошел уже 5й год. Мы убедились, что роль инженера технической поддержки – это хорошая стартовая площадка для специалистов любого другого направления. Она дает базовые знания о платформе, проектной методологии, инцидентах и системе работы с ними, которая учит мыслить в разрезе исследования проблем и поиска решений – навыка, необходимого специалисту любого направления. С роли инженера по технической поддержке у нас начинали Валерия Гаськова, Ксения Середкина, Артем Ярощук, Полина Шерстобитова, Игорь Артамонов, Дмитрий Игнатов. Сейчас это специалисты, которые успешно развиваются дальше в других направлениях.

 Менеджеры

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

• Консультанты выполняют анализ и формулируют требования к системе
• Разработчики проектируют и разрабатывают функционал системы
• Инженеры по тестированию выполняют тестирование системы
• Системные инженеры настраивают системное программное обеспечение и выполняют установку релизов системы
• Консультанты обучают сотрудников заказчика и выполняют внедрение системы
• Специалисты технической поддержки проводят патронаж системы и обеспечивают техническую поддержку

Возникает вопрос:

Если все проектные задачи выполняют специалисты конкретных ролей, то какие задачи у менеджера проекта?

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

Ответственность менеджера - достижение целей проекта с соблюдением сроков и бюджета. Для решения этой задачи менеджер собирает проектную команду, ведет актуальное планирование, получает информацию от сотрудников проектной команды и заказчика, помогает решать возникающие проблемы. Все эта деятельность не что иное, как управление рисками. В популярной книге Тома ДеМарко «Deadline. Роман об управлении проектами», в которой автор в художественной увлекательной форме описывает историю выдуманного проекта, можно встретить такой вывод о процессе управления:

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

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

Так мы получили 6 текущих направлений нашей практики, каждое из которых подразумевает свои профессиональные знания и навыки:

• Разработчики
• Консультанты
• Системные инженеры
• Специалисты по тестированию
• Инженеры технической поддержки
• Менеджеры

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

 Разработчики приложений

В некоторых проектах существует ряд задач, которые находятся на границе ролей Консультант и Разработчик. Это аналитические задачи, которые требуют погружения в технологические вопросы, а иногда включают и элементы программирования. Роль, которая лучше всего подходит для решения такого рода задач, принято называть, системный аналитик. Количество чисто аналитических задач в наших проектах небольшое. Поэтому выделить роль, в которой сотрудники решают только такие задачи нельзя. На помощь нам пришли тенденции вендоров по созданию ими продуктов, которые бы не требовали глубоких знаний программирования и проектирования сложных систем. Такими можно считать продукты ABBYY FlexiCapture, EMC D2, EMC xCP, задачи по построению отчетов к системам и т.п. Именно в рамках данных продуктов и задач мы создали, в свое время, направление разработчиков приложений. Сильного развития, к сожалению, оно у нас не получило, поэтому на текущий момент закрыто. Однако, рыночные тенденции, связанные с развитием СЭД российских производителей, могут вернуть потребность в нем. Вполне возможно, что у нас возрастет количество сотрудников, которые будут заниматься кастомизацией приложений на языках программирования, разработанных вендорами и мы вновь вернем направление разработчики приложений.

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