Предлагаю вниманию статью моего коллеги Вячеслава Льва о совместном использовании нескольких современных методологий управления.
Обращение от незнакомца в скайп с просьбой авторизоваться в 23-15 в субботу. Спрашиваю – зачем? – ответ – «хочу стать клиентом, зачем ждать понедельника и пробиваться через телефон, удобно, нашел имя в скайпе…». Заинтриговало, решил пообщаться.
Так ко мне впервые обратились представители IT сектора за помощью. Немного непривычно. Манера, скорость, тема.
Причина обращения понятна – компания быстро растет, появилась потребность в масштабировании, то, что раньше было возможно в рамках устных договоренностей, сейчас пришла пора в разумной степени формализовать, навести порядок, стандартизовать. Основателю компании показалась разумной система ISO 9001, но требовалась не бумага, а построение менеджмента на базе этой системы.
Следующая неожиданность – организационную диагностику пришлось проводить удаленно, тоже по скайпу. Сотрудники клиента разбросаны по разным городам, работают в своем режиме, дистанционно. Когда заговорил о необходимости провести групповую работу – пригласили в офис, но оказалось, что подразумевалась работа с несколькими дистанционно подключенными участниками – отказался, заменил на дополнительные интервью.
Общие впечатления от диагностики – нормальные проблемы быстрорастущей компании. Вроде бы понятно, как решать, но… практически все работают дистанционно и при этом чувствуют себя единым коллективом. С общими целями, нормальной атмосферой и желанием добиться лучшего результата. Молоды и достаточно мотивированы. Интересно.
В процессе диагностики стало понятно, что им нужен не столько ISO 9001, сколько ясность со стратегическими целями, операционными стратегиями, декомпозицией целей, уточнением функций и границ ответственности, системой стимулирования, стандартизацией повторяющихся действий и пр. Но опять-таки, это все вполне удобно делать на процессном представлении об организации, разумное применение международных стандартов здесь может помочь.
В общем, задача как у скульптора, – отсечь в камне все лишнее и оставить то, что представляется правильным. Найти грань, где стандартизация будет рациональной, а где нужно оставить гибкость и возможность развития быстрорастущей организации, возможность результативно создавать новый продукт.
Организация занимается как разработкой собственного программного обеспечения и его регулярным совершенствованием, так и поддерживающим сервисом, связанным с применением этого программного комплекса.
Планируя этот проект пришлось познакомиться с новыми для меня понятиями. Собственно, как оказалось, не совсем новыми.
AGILE и, что более инструментально, SCRUM.
Agile – набор принципов, определяется следующим манифестом [1]:
«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.»
SCRUM – это одна из концепций, предложенная для воплощения этих принципов в реальность.
При разработке этого подхода Джефф Сазерленд [2], опираясь на производственную систему Тойоты, формирование непрерывного потока создания ценностей и устранение потерь, подчеркивал, что в основе лежат принципы Э. Деминга, цикл PDCA. Как мы видим для специалистов по бережливому производству – термины все больше знакомые. Вопрос в их применении.
Согласно Джеффу Сазерленду [2], в основе SCRUM лежит простая идея – «ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляемся ли мы с заданием, в нужном ли направлении движетесь, создаете ли именно то, что на самом деле хочет получить заказчик.» Также постоянно выяснять – «есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам.»
При этом, согласно К.Хенрику и С.Маттиасу [3], SCRUM в себя включает следующие шаги:
Разделение организации на маленькие, кросс-функциональные, самоорганизующиеся команды
Разделение работы на маленькие, конкретные компоненты. Сортировка этого списка по приоритетам и оценка относительного объёма работы по каждому элементу.
Деление времени на короткие итерации фиксированной длины (обычно 1-4 недели) так, чтобы после каждой итерации проводилась демонстрация потенциально готового к использованию кода.
Оптимизация плана релиза и коррекция приоритетов совместно с клиентом, основываясь на данных, получаемых при рассмотрении релиза после каждой итерации.
Оптимизация процесс с помощью проведения ретроспективы после каждой итерации.
Для работы с системой Канбан К.Хенрик и С.Маттиас рекомендуют [3]:
Визуализируйте поток работ
Разбейте работу на части, выпишите каждый из пунктов на карточку и прикрепите на стену.
Подпишите столбцы, чтобы видеть на какой стадии находится каждое задание.
Ограничьте НЗР (WIP) (work-in-progress – незавершѐнная работа) – определите возможное количество незавершѐнных пунктов на каждой стадии рабочего процесса.
Измеряйте время выполнения задачи (lead time) (среднюю продолжительность времени для завершения одного пункта, иногда называемую «оперативным временем» (cycle time)), оптимизируйте процесс,
По свидетельствам тех IT специалистов, с кем лично общался, – SCRUM, – подход красивый, интересный, но реально не слишком часто полностью работающий на просторах бывшего СССР; c другой стороны Kanban, по их словам, более применим.
Опять-таки, все зависит от конкретных условий каждой организации, требований рынка, квалификации и заинтересованности организаторов процессов.
При этом SCRUM требует определенного уровня самосознания как у сотрудников, так и организаторов. Как я уже описывал в предыдущей статье для эффективного (осознанного) применения LEAN требуется определенная степень свободы в сознании, в SCRUM, если не ошибаюсь, те же требования.
Завершил диагностику, сформировали план изменений, провели обучение (в том числе очное, групповое).
Оказалось достаточно существенным найти грань между свободой и стандартизацией.
У меня всегда были непростые отношения с бюрократией: в юности она мне казалась совершенно ненужной вещью – ведь главное содержание, а не форма; но с обретением опыта, увидел, что от рационально внедренной бюрократии может быть изрядная польза:
использование общих для всех разумных правил,
быстрое тиражирование найденных лучших решений,
сокращение ошибок и непонимания,
разложение сложных действий на простые элементы,
возможность сокращения искажений при передаче информации и т.д.
Соединение разумной бюрократии (ISO 9001) и гибкого подхода AGILE, когда сотрудники прежде всего помнят о конечной цели, не возводя стандарты в абсолют, но пользуясь ими как Общей Договоренностью – наиболее целесообразной и разумной в настоящий момент, может быть вполне целесообразно. Естественно, при изменившихся условиях и/или новом понимании процесса, эти правила (стандарты) должны быть быстро и адекватно изменены. При этом, осмысление нестыковок, адекватная работа с несоответствиями ведет к совершенствованию процессов компании, уменьшению проблем при обслуживании клиентов.
Таким образом, оказалось, что, невзирая на непривычную (для меня) отрасль, смысл помощи быстро растущей организации не меняется:
формулирование целей компании на возможно обозримую перспективу по рынку,
декомпозиция этих целей в задачи для процессов,
построение модели процессов верхнего уровня (для того, чтобы понять, какие именно процессы существуют и насколько приоритетны в компании),
разбиение этих процессов на совокупность более мелких процессов и их разумная стандартизация, при этом по пути используем все необходимые инструменты оптимизации (Lean) [5].
совершенствование процессов на основе работы с несоответствиями (в т.ч. на основе обратной связи от клиентов)
При этом для разработки новых продуктов (в том числе программных) строим процессы на основе принципов AGILE и методик SCRUM, Kanban; берем то, что возможно для этой конкретной организации на данном этапе ее развития.
Подходы на базе Lean используем для того, чтобы процессы были выстроены оптимально. Понятно, что по дороге идет уточнение зон ответственности, минимально требуемые KPI, и прочее …, по необходимости.
После фиксации выстроенных процессов в стандартах – организация их проверки и возможности быстрого и рационального изменения стандартов, работа над повышением качества (в том числе и доработки программного обеспечения) через уточнение запросов клиентов и постановку работы с несоответствиями.
Далее, если будет внешняя потребность, можно и выходить на сертификацию по ISO 9001 в какой-либо приличной международной организации. Если это нужно для рынка…
