Принципы управления разработкой сервиса от Gov.uk

в 9:12, , рубрики: agile, Развитие стартапа, управление проектами, управление проектами и командой

Принципы управления разработкой сервиса от Gov.uk - 1

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

Основная задача меморандума Gov.uk – объяснить сотрудникам общие «правила игры», сформировать корпоративную культуру, помочь им определиться с ожиданиями друг от друга и от работы в целом. И хотя указанные принципы могут на первый взгляд показаться банальными, возможно, их стоит иметь в виду при создании собственного внутрикорпоративного «манифеста» – а то, насколько это важно и нужно ли это небольшим стартапам, мы обсудили с резидентами Акселератора ФРИИ.

Служба электронного правительства Великобритании (GDS) выявила 6 принципов управления «поставкой» сервисов. Руководствуясь этими принципами, вы сможете создать благоприятную внутреннюю культуру, в рамках которой будут создаваться новые и совершенствоваться текущие сервисы. Они заключаются в следующем:

  1. Не медлите с «поставкой» сервиса.
  2. Принимайте решения, когда необходимо и на должном уровне.
  3. Привлекайте к этому подходящих специалистов.
  4. Убеждайтесь во всем сами.
  5. Делайте только то, что приносит пользу.
  6. Доверяйте, но проверяйте.

1. Не медлите с «поставкой»

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

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

Мы оцениваем свой успех на основании предоставляемых услуг, удовлетворяющих требованиям пользователей. Успешное управление подразумевает:

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

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

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

2. Принимайте решения, когда необходимо и на должном уровне

Примите тот факт, что все со временем меняется. Убедитесь в том, что:

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

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

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

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

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

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

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

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

Принципы управления разработкой сервиса от Gov.uk - 2

3. Привлекайте к этому подходящих специалистов

Каждый должен:

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

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

На руководящих должностях должны находиться только те, кто способен:

  • принимать правильные решения;
  • управлять процессом и гарантировать поставку качественных услуг.

Они предоставляют поддержку команде-поставщику сервиса и привлекают нужных специалистов в нужное время в нужном месте.

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

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

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

4. Убеждайтесь во всем сами

Беседуя с группами поставки сервиса, вы можете сами убедиться в том, каких успехов они добиваются.

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

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

Каждый раз мы вместе составляем планы, беседуем с командами, чтобы узнать и открыто обсудить:

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

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

  • ежедневные «стендапы» длительностью от 10 до 15 минут, в рамках которых члены команды предоставляют сведения о выполненной работе за вчерашний день, полученных заданиях на сегодня и возникающих трудностях;
  • регулярные плановые совещания перед началом каждого из этапов, на которых команду вводят в курс дела;
  • регулярные обзоры или презентации по окончании каждого этапа, чтобы продемонстрировать завершенную на этом этапе работу и обсудить какие-либо вопросы и изменения, которые необходимо внести в процесс обслуживания;
  • регулярные ретроспективы, на которых команда может вспомнить, что прошло удачно, а что нет, и какие изменения следовало бы внести.

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

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

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

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

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

Принципы управления разработкой сервиса от Gov.uk - 3

5. Делайте только то, что приносит пользу

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

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

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

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

Группе поставки сервиса следует разработать нормативный документ, в котором прописаны:

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

Группы руководителей работают над созданием этого документа и помогают прийти к общему мнению и пониманию документа как внутри организации, так и за ее пределами.

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

Принципы управления разработкой сервиса от Gov.uk - 4

6. Доверяйте, но проверяйте

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

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

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

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

Мы обсудили материал со стартапами из Акселератора ФРИИ:

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

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

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

Из этих соображений мы пока в своей работе такие вещи не используем.

Анатолий Медведев, сооснователь проекта A2 Leasing System: Успешная команда должна понимать ценность своего продукта. Проект не может добиться успеха, если его целевая аудитория не видит в нем пользы. Это, пожалуй, главное, что должен найти и четко донести до своего клиента любой стартап. Реализация же самого проекта должна соответствовать намеченному плану. Это в первую очередь customer development и проверка гипотез по методу HADI, которые помогают двигаться проекту в правильном направлении.

Алексей Краснов, директор CloudStats: Я думаю, что идея такой «конституции» для команды – это очень интересно. Возможно, мы даже сядем и составим что-то подобное. В первую очередь, это полезно самим руководителям. Записав стратегию, видение и правила поведения на бумаге, всё можно сделать более понятным и осезаемым. А делая это понятным изначально для всей команды, можно еще и сэкономить кучу времени в процессе достижения цели.

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

Автор: frii_fond

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js