Как добиваться результата, управляя процессом разработки

    О чем это все


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

    Во-первых, часто говорят о работе на результате. О людях, ориентированных на процесс или на результат. Соотношение, как говорят, 95% к пяти. Рекомендую всем менеджерам проектов для начала великолепное видео Сергея Котырева в тему. Кстати, горячо рекомендую и другие видео посмотреть — Сергей достиг успеха на непростом рынке и знает, о чем говорит.



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

    Личный кейс


    Теперь моя история. Я долгое время бродил во тьме прокрастинации. И только недавно осознал, что часто не мог определить для себя, что же именно представляет собой результат, и потому плутал между разными задачами. Сейчас этого нет, у меня на каждый день, неделю есть вектор перед глазами, который я себе ставлю. А если быть точным — использую myTinyTodo. Очень удобный инструмент, гибкий, как Excel, и ставится на любой хостинг.

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

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

    Как быть с людьми


    1. RERO


    RERO — принцип «release early, release often» (релизьте рано, релизьте часто).
    Он должен проходить через весь ваш процесс мышления. Ибо в вашей голове варятся идеи, от уровня «сделать мегадорогой дизайн, суперпроект, и все сразу заложить, с правильной архитектурой» до уровня «бутстрапить максимально просто и дешево, выйти как можно скорее с MVP на рынок, четко и быстро собирать обратную связь, эволюционировать, выделять точки на рефакторинг и перестройку архитектуры под собранные живые данные и реальные бизнес-требования».

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

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

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

    2. Бонус от внедрения задачи


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

    3. Постановка, не вызывающая вопросов+дробление задач


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

    Отдельно скажу про то, что вы сами должны дробить задачу (или ваши ведущие) на куски с релизом 1-2 дня. Только так. И тогда вы сможете обеспечивать релизы, как Баду (5 релизов в день? или сколько у ребят, давно не смотрел).

    Конкретный пример из жизни. Нужно сделать сложную интеграцию двух исторически хаотически связанных баз клиентов. Я описываю только базовые механизмы от схемы (доработки на стороне CRM), держа в голове архитектуру всей системы. Если описать всю систему связей клиентов (отели, объединение отелей в сети, сетей- в суперсети, со сложными ACL) — то написание решения займет месяц.

    А простые доработки для решения части задачи (отели и сети и простая ACL) займут пару дней, и программист видит их законченными. Потому что задача грамотно разбита.

    4. Предпроверка рынка


    Это очень хорошо описывают в одном из курсов ребята из Стратоплана (пост проплачен, инфа 100%). Суть простая — не тратьте более $1000 на проверку рыночной идеи. Лучше всего просто провести целевой спам по клиентам и посмотреть, сколько людей оставит имейлы, чтобы ждать релиза функционала.

    Когда эту задачу объясняешь людям, то нужно донести, что проверка должна быть максимально простой и быстро. Занять один день разработка, если возможно. Сказать, что кодить месяц штуку, которая потом будет не нужна.
    И программисты — а они, как правило, умные люди — поймут, что лучше один день сделать штуку для проверки идеи, чем месяц делать то, что потом не будет востребовано. Работает.

    5. Объяснение сути вещей


    Иногда есть люди-проблеморешатели. Я сам такой, думаю, это очень важное качество для программиста и для менеджера проектов.
    Человек любит решать чужие проблемы.

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

    Пример из жизни. Объясняю задачу связи двух хаотических баз и что нужно получить. Программист сам (! красавец и умница) предлагает разные отчеты и фильтры, делает выводы этих отчетов. И вся картина — как на ладони. Что позволило получить видение, как должна быть система устроена.

    6. Тиражируемые (повторно используемые) решения


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

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

    А что дальше?


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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 9

      +10
      Смешались в кучу кони, люди…
        +4
        Японцы могут поспорить с цитатой на КДПВ
          +1
          Имхо, тут самая тонкота — хрупкий баланс между связкой пунктов 1 и 4 и, собственно, 6. Зачастую MVP представляет из себя работающий на костылях кусок говнокода, и тиражировать такое решение — не лучшая идея. Так что тут не хватает промежуточного пункта — рефакторинг успешных продуктов с целью повторного использования.
            0
            Любой проект сделанный с нуля меньше чем за полгода — MVP кусок говна. Так что сразу же в первом пункте написано про всё это.
            +1
            Все относительно. Я кучу раз видел как из-за плохой и непродуманной архитектуры потом отгребали кучу проблем и в деньгах выигрыша от куяк-куяк-и-в-продакшен не было, скорее даже проигрыш. Вопрос только в том, сколько денег реально теряется на более позднем time-to-market.
              0
              Из-за непродуманной архитектуры (например, не рассчитанной на высокую нагрузку) в дальнейшем могут быть даунтаймы и простои, что естественным образом ведет к проигрышу в деньгах.
                +1
                если проект доживет до денег
                0
                Вот только можно долго долго выводить идеальную архитектуру и выйти на рынок, когда ты там уже не нужен.
                  0
                  конечно есть такие рынки, где все решают дни и часы, но если только это не пустая ниша и ты не первый, насколько оно вообще себя оправдывает, может, вообще на этих рынках компании живут считанные месяцы?

              Only users with full accounts can post comments. Log in, please.