О чем это все

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

Во-первых, часто говорят о работе на результате. О людях, ориентированных на процесс или на результат. Соотношение, как говорят, 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. Тиражируемые (повторно используемые) решения

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

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

А что дальше?

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

Автор: Cord

Источник