Кто на свете всех милее: суррогатная мать или мачеха?

Меня зовут Екатерина, я живу и работаю в сибирском городе Иркутске, возглавляю департамент информационных систем в «Иркутской нефтяной компании (ИНК)».

«Иркутская нефтяная компания» – это самая крупная независимая нефтегазодобывающая компания в России. Ее штат сотрудников насчитывает более 13 тысяч человек.

Мое подразделение занимается всем, что связано с информационными системами – их внедрением, разработкой, развитием, сопровождением, контролем качества данных и, в частности, нормативно-справочной информации.

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

Сегодня я расскажу о нашем дальнейшем эволюционном развитии – о разделении проектной и продуктовой команд.

В последние годы «Иркутская нефтяная компания» активно растет вширь:

• когда-то компания была просто нефтяной;

• потом она стала нефтегазовой;

• потом – нефтегазохимической.

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

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

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

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

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

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

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

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

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

Программный продукт на своем жизненном пути переживает несколько стадий. Коротко это выглядит так:

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

• Далее идет процесс непосредственной разработки программного продукта – здесь работают программисты, тестируют консультанты, дорабатывают по замечаниям снова программисты. Эта фаза отвечает за то, что происходит с программным продуктом до того, как его увидит заказчик.

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

• Промышленная эксплуатация – это этап стабильной эксплуатации системы. В нашем случае он одновременно подразумевает достаточно активное развитие системы под заказчика.

По нашему опыту:

• на этапах планирования, разработки и опытной эксплуатации над продуктом работает проектная команда;

• а за дальнейшее развитие системы отвечает уже отдел сопровождения.

Давайте сравним наш программный продукт с человеком.

• В данном случае планирование – это некая подготовка к беременности. Мы будем считать, что наши родители, когда захотели завести ребенка, они ответственные и все-таки к беременности готовятся.

• Этап разработки – это сама беременность.

• Опытную эксплуатацию я сравнила бы с родами и ранним послеродовым периодом.

• И промышленная эксплуатация – это дальнейшее развитие, рост нового человека.

Чтобы не сравнивать отдел внедрения с матерью, которая родила ребенка и бросила его, проведем более позитивное сравнение с суррогатной матерью.

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

Специализация консультантов в департаменте информационных систем на задачах внедрения или развития

Таким образом, у нас были созданы два отдела.

• отдел внедрения информационных систем («суррогатные матери»);

• отдел развития («мачехи»).

Когда мы проводили это разделение, нам пришлось учитывать профессиональные особенности наших консультантов.

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

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

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

Кроме разницы в отношении к системе на разных этапах, было замечено, что:

• сотрудники отдела внедрения легко сходятся с заказчиками и охотно знакомятся с проектной командой;

• а сотрудники отдела развития сосредоточены на выстраивании долговременных отношений с заказчиком.

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

В тот момент я не нашла каких-то тестов, которые бы могли подсказать, в какой сфере сотрудник будет более эффективен – во внедрении или в развитии. Но я не думаю, что если бы такие тесты были, мы бы стали 100% полагаться на их результаты. Залогом успешного разделения стало то, что мы:

1. Четко определили разницу между задачами двух отделов.

2. Учитывали пожелания сотрудников – каждый говорил, куда он хочет.

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

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

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

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

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

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

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

Итак, заказчик Зинаида Петровна на проекте внедрения системы несколько месяцев работала с консультантом по внедрению Максимом. Они вместе внедрили хорошую систему, прошли этап опытной эксплуатации. Конечно, было реализовано не все, что хотела Зинаида Петровна, но ее заверили, что с переходом системы в промышленную эксплуатацию ее развитие не прекращается. И Зинаида Петровна настроена довести систему до идеала – доработать ее и внести в нее всю ту функциональность, которую она хочет.

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

Что мы слышим в этот момент от заказчика? Заказчик говорит: «У нас с Максимом уже выстроены взаимодействия, он меня понимает с полуслова, ему не нужно ничего объяснять с нуля. Кристина систему не знает так хорошо как Максим. Пусть вообще Кристина берет новый проект, а Максим занимается дальше моей системой» и прочее. Наверняка все из вас это слышали не раз, и вообще это происходит всегда и на каждом проекте.

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

Совет №1. Как можно раньше подключайте к проекту консультанта по развитию

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

Расскажу, как это правило реализуется в нашей компании.

На экране вы видите матрицу разделения задач сотрудников внедрения и развития на разных этапах проекта.

• Непосредственно написание ТЗ – это задача консультанта по внедрению. При этом сотрудник развития обязательно знакомится с ТЗ, задает вопросы, делает замечания и выдвигает предложения по внесению изменений в документ.

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

• Демонстрацию системы заказчику (приемо-сдаточные испытания) проводит консультант по внедрению, но сотрудник развития на этом мероприятии тоже обязательно присутствует.

• На этапе тестирования системы заказчиком, а также на этапе опытной эксплуатации:

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

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

• После завершения опытной эксплуатации начинается промышленная эксплуатация – сотрудник развития лично занимается развитием системы по заявкам от пользователей или уже по собственной инициативе. Он обучает отдел сопровождения, который становится первой линией, и занимается актуализацией инструкций уже на протяжении всей эксплуатации.

Благодаря такой схеме:

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

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

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

Совет №2. Полностью изолируйте консультанта по внедрению от заказчика

Не позволяйте консультанту по внедрению взаимодействовать с заказчиком напрямую после того как система переведена в промышленную эксплуатацию.

Нарушение этого правила может негативно повлиять на ход проекта:

1. Это нарушает установленный процесс – все должны следовать четким правилам и заниматься своим делом.

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

3. Также возникает вполне логичный вопрос: зачем тогда нужен консультант по развитию, если задачами клиента продолжает заниматься сотрудник, который внедрял? Может быть тогда лучше перевести сотрудника внедрения в отдел развития, и пусть он дальше занимается этой системой?

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

Первое время после разделения у нас были такие проблемы, но со временем соблюдение этого правила стало само собой разумеющимся – сейчас таких проблем у нас нет.

Совет №3. Установите правила взаимодействия между консультантами

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

У нас на этот период действуют следующие правила:

1. Если возникают вопросы или пожелания по доработке системы, они обязательно передаются на первую линию – в отдел сопровождения.

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

3. Также бывает, что сотрудник внедрения, наоборот, обращается к сотруднику развития, когда обычно новая система внедряется, интегрируется с уже существующей, и нужны какие-то консультации внедренцу. Это двустороннее и эффективное командное взаимодействие.

Совет №4. Учитывайте характер сотрудников при определении отдела

Обязательно нужно учитывать характеры сотрудника при определении дела.

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

Даже если сотрудника удается перевести в другой отдел, это все равно несет негативные последствия.

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

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

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

Надо ли держать проектную команду на этапе промышленной эксплуатации?

Возникает вопрос: как задержать проектную команду на проекте? Есть два способа:

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

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

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

• Во-первых, цели проекта не достигнуты, система не удовлетворяет предъявляемым к ней требованиям.

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

• Как правило, проектная команда после перевода расформировывается, идет на другие проекты и собрать ее практически нереально.

• И даже если это удается каким-то образом сделать, это будут совсем другие деньги и совсем другие сроки.

Поэтому если есть объективные аргументы, чтобы задержать проектную команду, это обязательно нужно делать.

Что же касается необъективной задержки, здесь все не так однозначно – особенно, если посмотреть с разных сторон.

• Со стороны заказчика:

  • Конечно, заказчику нравится как можно дольше взаимодействовать с командой внедрения.

  • Но если исполнитель – это другая компания-контрагент, ее необъективная задержка на проекте может существенно увеличивать стоимость внедрения.

• Со стороны внедрения:

  • Мы наблюдаем порой некую привязанность команды к системе, к заказчику – команда переживает, что будет с заказчиком после расставания с ней, поэтому неосознанно она готова какое-то время задержаться на проекте.

  • Но проектники потому и проектники, что они больше эффективны на проектных задачах и выгорают на текучке. И простаивание других проектов, которые ждут команду, может быть весьма дорогим удовольствием.

• Если говорить о развитии, то:

  • Чем больше задач сделает внедрение, тем меньше останется задач у развития.

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

Заключение

Поэтому на вопрос: «Нужно ли держать проектную команду в проме» однозначного ответа нет, но я бы сказала так.

• Если вы внедряете, развиваете и сопровождаете собственными силами – задерживать проектную команду на проекте нет смысла. Если проектные задачи действительно выполнены, передавайте систему в пром и пусть каждый занимается своим делом.

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

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

В любом случае, как бы вам ни пришлось делить сотрудников на команды, главное при этом – оставаться единой командой.

Вопросы и ответы

Есть ли у вас подобное деление по командам для разработчиков? Вы подробно рассказали про консультантов внедрения и консультантов развития, а программисты у вас как-то делятся по командам или нет?

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

А приоритеты как-то расставляются, если разработчик уже на новом проекте внедрения?

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

Как вы делили сотрудников на развитие и на внедрение? По каким качествам вы определяли, кого куда определить?

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

А если вы считаете, что сотрудник более эффективен во внедрении, а он хочет в развитие? Что приоритетнее: его мнение или мнение людей, которые оценили его, как более эффективного в другой отрасли?

Не было такого, чтобы коса нашла на камень, и мы никак не могли договориться. Всегда договаривались. Но думаю, что если бы такое произошло, мы бы дали сотруднику шанс все-таки пойти туда, куда он хочет, показать себя. Если бы не получилось, мы бы потом аргументированно сказали: «Переводись, это не твое».

А зарплата у них при этом одинаковая?

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

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

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

А системы грейдов у вас нет? Не может быть, что в одном отделе сотрудник зарабатывает меньше или больше?

У нас грейды сейчас внедряются, но система еще несовершенна. Но в рамках отдела нет большого разброса – 1-2 грейда. И по должностям, конечно, делятся: простой, ведущий, главный. Такое есть.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.