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