Как разобраться с бардаком, доставшимся в наследство
Когда мы переехали в новый офис, у нас возникла такая желанная атмосфера стартапа. Единое пространство, пуфики, настольный футбол так и располагали к творчеству. Только мы не были настоящим стартапом — нам в наследство из прошлого досталось очень много недоделанных задач.
На момент запуска был список из нескольких десятков проектов, которые уже были в работе. Самой масштабной было — доделать интернет-банк Альфа-клик (смена платформы). Сложность заключалась в том, что необходимо было решить не только текущие задачи, увеличив скорость их решения, но и начать решать новые. Еще одна сложность заключалась в том, что точного описания новых задач не было. Одной из целей, которую руководство банка поставило перед Альфа-Лаб перед запуском, было выпускать по вау — фишке раз в квартал. Под вау — фишками понимались дополнения к интернет- и мобильному банку, которые вызывали бы у пользователя одноименный возглас. Критериев, что должно вызвать такой эффект, а что нет, не было.
Как будто в Москве мы сели в обычный поезд до Санкт-Петербурга и прямо в пути должны были переделать его в “Сапсан”. При этом рабочие друг друга не понимали.
В банке от нашего нового подразделения ждали больших результатов. Или большого провала. На общих встречах было очень интересно наблюдать за коллегами. Они делились на две группы: одни смотрели на нас с надеждой, а другие — с плохо скрываемым скепсисом. Но и те, и другие требовали поскорее решить их задачи: одновременно, шустро и не интересует как. «Вы же доделаете Альфа — клик к среде? Эта задача супер важная, её нужно сделать не сдвигая остальные. А вот эту очень нужно сделать, так как наш босс считает, что она очень важная! Вы уже придумали вау — фишки?», спрашивали на совещаниях. «Да, конечно», отвечали мы.
Думаю мы выглядели закрытыми и поверхностными му… людьми, которые всем все обещают и не рассказывают, как это сделают. Но дело в том, что мы сами совсем не понимали, что делать. И постепенно рос эмоциональный долг. А говорить «нет», не предлагая альтернативы, глупо.
Для того, чтобы начать говорить, нам не хватало времени разобраться и собственного авторитета. Первое мы начали закрывать после аудита, а второе пришло с первыми результатами.
Около двух месяцев наша команда училась разговаривать друг с другом. Несмотря на то, что аналитики и разработчики сидели теперь рядом, друг с другом они особенно не общались. Находится в одной комнате было необычно, все привычные шаблоны были порваны.
Эта ситуация выглядела как паралич: все очень сильно старались делать свою часть работы, но общего результата из этого не получалось.
Взгляд со стороны:
В какой-то я момент решила прибегнуть к нетрадиционным на тот момент методологиям для банка. За несколько месяцев до создания Альфа-Лаб в банке проводили тренинги по гибким методологиям. Тренинги вел Никита Филиппов — один из основателей консалтинговой компании ScrumTrek. Мы поговори, порисовали, и Никита предложил провести аудит.
«Слово «аудит» звучит как какой-то термин из бухучета, как будто это проверка, по результатам которой ты либо сядешь в тюрьму, либо нет. На самом деле, он был просто взглядом со стороны, который помогает начать решать проблемы. У аудита две ключевые ценности: свежий взгляд и обращение к незаинтересованному авторитету — мнению.
Бывает, что работу консультантов обесценивают (они же за результаты не отвечают). Есть даже анекдот про них:
Однажды пастух, следящий за большим стадом, встретил мужчину. Тот ему говорит: «Хочешь, я посчитаю, сколько у тебя баранов в стаде? За это я возьму себе одного барана». Пастуху стало интересно, и он согласился. Мужчина долго ходил вокруг баранов, делал пометки в блокноте, и вот спустя несколько часов выдал результат:
«У тебя 342 барана в стаде».
«Все так, — ответил пастух. — Забирай своего барана».
Мужчина забрал гонорар и уже собрался уходить. И тут пастух его спрашивает «Ты работаешь консультантом?»
«Да. Как ты догадался?» — удивился мужчина.
«Ты взял мою собаку вместо овцы».
В общем, нужен был именно такой человек со стороны.
Аудит занял ровно неделю. Есть мнение, что 7 дней — это предельная точка насыщения информацией. Все данные, собранные на вторую неделю уже повторяются.
Что выявил аудит?
Система производства была построена так, что люди находились в состоянии непрерывной катастрофы. Дедлайны регулярно срывались, и что-то двигалось благодаря героическим усилиям команд. И все винили друг друга.
Чтобы понять, кто реально виноват, в ходе аудита пришлось поговорить со всеми. Всех ключевых сотрудников Лабы попросили описать процесс своей работы и рассказать, какие проблемы они видят в этом процессе.
Процесс рисовался в виде схемы. Заторы в работе люди указывали с помощью стикеров, которые вешались на советующее место в схеме. Конечно, у каждого отдела/группы было свое видение проблем. Аналитики рисовали один и тот же процесс по-своему, программисты по-своему. Тем не менее набралось большое количество общих проблем, которые были классифицированы по отделам/группам.
В результате получилась общая схема, состоящая из квадратиков и стрелочек, где квадратики были полезной работой, а стрелочки — нет. Эта схема называется Value streem map. Она позволила посчитать кпд всей работы.
Оказалось, что никто не думал о конечной цели всей работы, то есть о клиентах. Вся культура была нацелена на запуск проектов и выполнение своего этапа куска работы, потому что это было в KPI.
Продуктовые менеджеры мыслили не в терминах нужд потребителей, аналитики выполняли задачи продуктовых менеджеров, программисты писали код, не очень понимая, что за продукт будет в итоге, а на тестировщиков сваливался этот продукт коллективной никому не нужной работы — кривой продукт, который уже поздно было менять.
Все это сопровождалось кучей бесполезной документации, которую никто не читал. Процессы были построены следующим образом — необходимо было написать документацию и кинуть её в разработчиков. Что будет дальше аналитиков уже не особенно волновало, они брали в проработку уже следующую задачу. Но пока она писалась, она просто устаревала.
Пример, который отлично показывает эту схему работы — запуск bump-переводов. В 2011 году это было модной фишкой. Перевести деньги можно, стукнув свой смартфон о смартфон получателя. Звучит очень круто. Но на практике оказалось, что ими никто не пользовался. Почему? Возможно, потому , что никто не подумал о пользователе. Продуктологи подумали, что эта фича может понравится потребителям, выдали аналитикам задание, написать техническое задание и спросили, через сколько будет готов проект. Получив ответ «через три месяца», они обрадовались и больше не следили за работой. И только спустя три месяца они пришли смотреть на результат.
Такая же история была с запуском PFM в интернет — банке (сервис, который анализирует траты пользователей). Все очень долго писали документы, долго что-то делали, а на выходе сделали громоздкое, некрасивое решение. И когда стало понятно, что это факап, вместо того, чтобы сесть и обсудить, почему так произошло, все стали валить проблемы друг на друга. И переезд в единый офис с новой рассадкой этого не изменил. Хотя все сели в одном пространстве, люди продолжали кучковаться по специальности — аналитики сели в свой уголок, продуктологи — в свой.
У команды были проблемы с коммуникациями. Однажды произошла просто феерическая история. У трех людей была назначена рабочая встреча. Двое из них сидели почти рядом, буквально в двух метрах друг от друга. Третий участник опаздывал на встречу. Вместо того, чтобы поговорить и всем вместе придумать какой-то выход из ситуации, все трое строчили письма друг другу с обвинениями. Их единственной целью было прикрыть себя, чтобы начальство не наказало.
У части сотрудников было «стаканное мышление». Каждый жил в своем стакане — на него лилась вода, и он под ней плескался. Но продукты делаются только вместе. Чтобы все работало сотрудники должны были стать сообщающимися сосудами.
Еще одним большим вызовом был очень длинный цикл работы. Выглядело это так — тестировщик нашел проблему, и идет к программисту. Тот ему говорит — я это делал 3 недели назад, мне надо вспомнить, что там вообще написано. Выясняется, что он уже поверх этой ошибки сделал другую работу, и ошибок будет еще больше. В итоге проблемы нарастали как снежный ком.
В результате аудита было предложено полностью поменять процессы в Альфа-Лаб и внедрить Agile.
Как и что конкретно, читайте в следующем посте, в котором будет небольшой сюрприз. Следите:-)
