Стоит сейчас внедрять каскадную модель управления проектами? Что важно определить при начале работы сотрудника в компании? Почему опыт в 1С:Франчайзи может быть негативным?
Рассказываю вам историю из личного опыта работы в компании Древляндия (замаскированный плод моей фантазии, поэтому, друзья, не ищите её в поисковике), где работаю сейчас в должности руководителя проектного офиса.
С чего всё начиналось
Со своей командой мы прорывались сквозь консервативные и бюрократические взгляды учредителей, закоренелых и привыкших работать "как обычно" пользователей с очень простой целью - нам нужно привести в порядок зоопарк учетных систем. Основная учетная система - 1С:Управление торговлей 11.3, разумеется, с россыпью изощренных доработок.
Ключевая проблема здесь была в том, что сопровождающий всю работу в 1С человек был настолько загружен поступающими к нему вопросами, просьбами и задачами, что у него физически не хватало времени, чтобы разрулить все это. Он ударялся в доработки без разбора с типовым функционалом и без выяснения вариантов с заказчиком «а вы знаете, как было бы правильнее?».
С головой в омут
Как только мне довелось начать работу в компании, у руководителя не было четкого понимания моего функционала (да у меня самого его не было), все происходило как-то по наитию. Должность была "Руководитель группы разработки 1С" - многообещающе, но никто даже не объяснил функциональные обязанности, и первым делом я начал пилить какие-то обработки по запросу ключевых пользователей. На тот момент команда была следующая:
1. 3 программиста 1С с разной квалификацией:
- Опытный разработчик в возрасте: действовал по принципу "если просят, значит делаю и как можно скорее" - очень умный мужик как в программировании на 1С, так и в администрировании 1C/SQL/виртуальных машин и др. К сожалению, в тех условиях, в которые его загнали, он совсем не учитывал принципы доработки типовых конфигураций и в большинстве просто дорабатывал типовой код без каких-либо комментариев.
- Разработчик-самоучка в возрасте с небольшим опытом в разработке на 1С. Технарь, хорошо обучающийся и старающийся сам искать решения возникающих проблем (хороший навык для сотрудника). Его ментором был первый опытный разработчик, и зачастую их хаотический код, слитый в одно хранилище, превращался подобно самым современным песням Скриптонита в текст, который не разобрать от слова совсем.
- Третий разработчик молодой и хорошо разбирался в платформе 1С, но были и у него скелеты в шкафу - это отсутствие знаний по типовым конфигурациям. На фоне этого, выданный ему проект от директора по ИТ реализовывался практически полностью самописно и без использования типового функционала.
2. Руководитель проектов.
С этой командой я знакомился постепенно и очень тяжело, потому что изначально фронт работы и полномочий не сформулировали. Шло время и мы начинали работать с задачами на поддержке: разбирались в инцидентах, ошибках и прилетающих нескончаемых доработках. Помогали пользователям и думали, что когда-то настанет момент и шквал проблем исчезнет. Бесконечные ремонты доработанного функционала не позволяли делать толковые задачи для развития. Были предприняты попытки по реализации интересной задачи по разработке АРМ (автоматизированных рабочих мест) для пользователей одного из бизнес-процессов в компании. Проект был сформулирован в виде набора задач с примерной оценкой и распределением по ответственным: разработку я брал на себя, а все процессы по общению с бизнесом - на менеджере проектов.
Выглядит довольно просто, но под капотом там запутанные механизмы по автоматизации всех действий пользователей, которые работают только с несколькими кнопками в АРМ.
В итоге задачи я делал в одиночку и очень долго (объем трудозатрат на разработку порядка 500 часов), потому что оставалось на них время только после основного рабочего дня и решения запросов поддержки. Через год такой работы стало понятно, что нужно менять схему и структуру работы департамента.
Свет в конце тоннеля
Так и появилось разделение на проектный офис и техническую поддержку. От меня стало требоваться организовать работу проектного офиса, и я, опираясь на свой опыт работы в 1С:Франчайзи, стал строить каскадную модель управления проектами. Мы проработали формы документов для оформления бумаг по уставам проектов, приёмо-сдаточным испытаниям и передаче в эксплуатацию. Постарались выделить проектную команду, которая делала только лишь задачи по проектам. И вот началась работа по нашему первому проекту: внедрение CRM. Мы расписали все задачи, составили диаграммы Ганта на пол года вперёд, расставили оценки по задачам и исполнителей по ним. Все согласовали с бизнесом и начали долгую работу по каскадной модели.
Через пол года мы, разумеется, ничего не закончили, и осталось ещё достаточно работы по внедрению. Проект начал свою работу, как и планировалось, по выбранным торговым точкам в Москве, на которых нужно было провести тестирование. Вся команда после запуска получила нагоняй от учредителей по причине того, что мы не успели внедрить CRM во всей компании в оговоренные сроки. Разумеется!..никто и не планировал изначально за такой срок раскатать везде систему - это требовало уйму работы. Предстояло оптимизировать работу с CRM, организовать связку с телефонией и обучить каждого сотрудника во всех регионах присутствия с прохождением тестирования.
Сейчас я стал осознавать, что выбор каскадного подхода происходил по привычке и скорее всего был ошибочным. Мы сдали проект через 9 месяцев после старта внедрения, но есть одно "но": все это время мы не занимались больше ничем, кроме этого проекта.
И кто бы что ни говорил, мы будем жить!
Что ж, это была краткая история моего опыта внедрения каскадной модели и начала работы в Древляндии. Думаю, что вы догадываетесь о том, что такая скорость работы не устраивала ни нас, ни топ-менеджеров, ни наших учредителей. Двинемся дальше, и я расскажу, что у нас изменилось прямо сейчас!
Выводы
Считаю важным в своих публикациях подводить итоги и извлекать максимум пользы из полученного опыта.
- При выходе на новую работу необходимо составлять для себя цели и описывать свой функционал, согласовав его со всеми руководителями.
- Знакомство с компанией нужно начинать с определения внутренней ИТ архитектуры (если её нет, то составить) и выяснения компетенций сотрудников отдела.
- Нельзя автоматизировать хаос: основы работы учетных систем - правильная организаций процессов внутри неё и снаружи (взаимодействие пользователей с программой). Если здесь сбои - значит требуется немедленная ревизия или обновление системы.
- Выбор проекта для работы и его значимость: совместная работа ИТ с бизнесом по выстраиванию приоритетов. Проект должен приносить ощутимую выгоду для компании, тогда деятельность ИТ подразделения станет осязаема.
- Эффективность и гибкость в проектных подходах - одни из важных критериев работы. Демонстрация результата заказчикам и его постоянная актуализация позволяет "продавать" свою работу и оставаться в одном контексте с бизнесом.