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

https://www.gov.uk/service-manual/governance/governance-principles
  • Перевод


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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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



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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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



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


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

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

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

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

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

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

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

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



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


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

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

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

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

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

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

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

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

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

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

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

Это вообще здорово, когда вся команда видит конечную цель, а не просто работает по задачам, которые им «спускают сверху». Однако, не стоит слишком усердствовать. Меморандум на страницу – не более. Четкое разделение ролей, задач и обязанностей, необходимое в крупном бизнессе, невозможно в маленьких командах. Необходима гибкость, возможнсть быстро переориентироваться и экспериментировать. Для стартапа это особенно актуально, потому что за время проекта можно переработать десятки различных гипотез и подходов.
  • +12
  • 3,2k
  • 6
Фонд развития интернет-инициатив 70,17
Экспертиза и инвестиции для стартапов
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 6
    –1
    На руководящих должностях должны находиться только те, кто способен:

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

    Вот спасибо! Что бы я делал без этих советов. Я тоже могу парочку накидать:

    Каждый программист в команде должен:
    • Уметь выполнять свою работу
    • Писать качественный код
      +2
      Предисловие вроде как все это поясняет. Может не вчитывались просто
        +4
        Придраться к одному слову — so mature. И пох на то, что цикл материалов крайне полезный, конечно, можно ведь плюсов срубить)
          –3
          Очевидно вам не приходит в голову, что тут можно не «плюсы срубать», а высказывать свое мнение. Попробуйте и вы, может понравится.

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

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

          Очевидно, что про agile переводчик тоже ничего не слышал.
            +1
            У меня просто встречный вопрос — о чем ваши комментарии? Что за наезды «разработчик не слышал» и так далее? Я не вижу у вас в профиле опубликованных материалов, которые бы показывали ваш класс.

            Конечно, с одной стороны не надо быть курицей, чтобы разбираться в яичнице, с другой я вот публиковалась и на Хабре, Гиктаймсе и на Мегамозге, и понимаю, что есть совершенно разная аудитория, кто-то может не знать очевидные для других вещи. Поэтому нужно как-то потактичнее быть, а то вы с одной стороны мнение высказали, с другой наехали на переводчика — при этом не опубликовав ни одного поста. Выглядит не очень красиво, пусть даже вы тысячу раз правы (с чем можно спорить, опять же).
              0
              вы с одной стороны мнение высказали, с другой наехали на переводчика — при этом не опубликовав ни одного поста.


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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое