Как разобраться с бардаком, доставшимся в наследство

0
15259289 10211593649425112 8149987295506777173 o
Надежда Авданина
Экс-директор центра инноваций и технологий электронного бизнеса, Альфа-Лаборатория

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

На момент запуска был список из нескольких десятков проектов, которые уже были в работе. Самой масштабной было — доделать интернет-банк Альфа-клик (смена платформы). Сложность заключалась в том, что необходимо было решить не только текущие задачи, увеличив скорость их решения, но и начать решать новые. Еще одна сложность заключалась в том, что точного описания новых задач не было. Одной из целей, которую руководство банка поставило перед запуском, было выпускать по вау — фишке раз в квартал. Под вау — фишками понимались дополнения к интернет- и мобильному банку, которые вызывали бы у пользователя одноименный возглас. Критериев, что должно вызвать такой эффект, а что нет, не было.

Как будто в Москве мы сели в обычный поезд до Санкт-Петербурга и прямо в пути должны были переделать его в “Сапсан”. При этом рабочие друг друга не понимали

В банке от нашего нового подразделения ждали больших результатов. Или большого провала. На общих встречах было очень интересно наблюдать за коллегами. Они делились на две группы: одни смотрели на нас с надеждой, а другие  —  с плохо скрываемым скепсисом. Но и те, и другие требовали поскорее решить их задачи: одновременно, шустро и не интересует как. «Вы же доделаете Альфа — клик к среде? Эта задача супер важная, её нужно сделать, не сдвигая остальные. А вот эту очень нужно сделать, так как наш босс считает, что она очень важная! Вы уже придумали вау — фишки?», — спрашивали на совещаниях. «Да, конечно», — отвечали мы.

Думаю, мы выглядели закрытыми и поверхностными му… людьми, которые всем все обещают и не рассказывают, как это сделают. Но дело в том, что мы сами совсем не понимали, что делать. И постепенно рос эмоциональный долг. А говорить «нет», не предлагая альтернативы, глупо.

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

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

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

Взгляд со стороны.

В какой-то я момент решила прибегнуть к нетрадиционным на тот момент методологиям для банка. За несколько месяцев до создания Альфа-Лаборатории в банке проводили тренинги по гибким методологиям. Тренинги вел Никита Филиппов — один из основателей консалтинговой компании ScrumTrek. Мы поговорили, порисовали, и Никита предложил провести аудит.

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

Бывает, что работу консультантов обесценивают (они же за результаты не отвечают). Есть даже анекдот про них:

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

«У тебя 342 барана в стаде».

«Все так, — ответил пастух. — Забирай своего барана».

Мужчина забрал гонорар и уже собрался уходить. И тут пастух его спрашивает: «Ты работаешь консультантом?»

«Да. Как ты догадался?» — удивился мужчина.

«Ты взял мою собаку вместо овцы».

В общем, нужен был именно такой человек со стороны.

Аудит занял ровно неделю. Есть мнение, что 7 дней — это предельная точка насыщения информацией. Все данные, собранные на вторую неделю уже повторяются.

Что выявил аудит?

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

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

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

В результате получилась общая схема, состоящая из квадратиков и стрелочек, где квадратики были полезной работой, а стрелочки — нет. Эта схема называется Value streem map. Она позволила посчитать кпд всей работы.

Общая схема работы (Value streem map) на момент аудита

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

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

Все это сопровождалось кучей бесполезной документации, которую никто не читал. Процессы были построены следующим образом — необходимо было написать документацию и кинуть её в разработчиков. Что будет дальше, аналитиков уже не особенно волновало, они брали в проработку уже следующую задачу. Но пока она писалась, она просто устаревала.

Пример, который отлично показывает эту схему работы —  запуск bump-переводов. В 2011 году это было модной фишкой. Перевести деньги можно, стукнув свой смартфон о смартфон получателя. Звучит очень круто. Но на практике оказалось, что ими никто не пользовался. Почему? Возможно, потому что никто не подумал о пользователе. Продуктологи подумали, что эта фича может понравится потребителям, выдали аналитикам задание, написать техническое задание и спросили, через сколько будет готов проект. Получив ответ «через три месяца», они обрадовались и больше не следили за работой. И только спустя три месяца они пришли смотреть на результат.

Такая же история была с запуском PFM в интернет — банке (сервис, который анализирует траты пользователей). Все очень долго писали документы, долго что-то делали, а на выходе сделали громоздкое, некрасивое решение. И когда стало понятно, что это факап, вместо того, чтобы сесть и обсудить, почему так произошло, все стали валить проблемы друг на друга. И переезд в единый офис с новой рассадкой этого не изменил. Хотя все сели в одном пространстве, люди продолжали кучковаться по специальности — аналитики сели в свой уголок, продуктологи — в свой.

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

У части сотрудников было «стаканное мышление». Каждый жил в своем стакане — на него лилась вода, и он под ней плескался. Но продукты делаются только вместе. Чтобы все работало сотрудники должны были стать сообщающимися сосудами.

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

В результате аудита было предложено полностью поменять процессы в Альфа-Лаб и внедрить Agile

Как и что конкретно, читайте в следующем посте, в котором будет небольшой сюрприз. Следите:-)

Свежие статьи на почту