О чем все это Это будет короткий пост. Сначала личная история, а потом как применить это на практике в управлении сотрудниками.
Чисто опыт, никаких теорий.
Во-первых, часто говорят о работе на результат. О людях, ориентированных на процесс или результат. Говорят, что соотношение составляет 95% к пяти.
Я рекомендую всем менеджерам проектов отличное место для старта.
видео Сергей Котырев о теме.
Кстати, настоятельно рекомендую посмотреть и другие видео - Сергей добился успеха на сложном рынке и знает, о чем говорит. 
Видео ответит на ваши вопросы о том, почему окружающие вас люди (если вы по натуре проект-менеджер) не хотят брать на себя ответственность, часто не хотят выполнять задачу так, как это сделали бы вы, и вообще от вашего точки зрения, являются малоэффективными и малоэффективными.
Они это не делают специально, просто такова природа людей, ориентированных на процесс в жизни.
Личное дело
Теперь моя история.Долгое время я блуждал во тьме прокрастинации.
И только недавно я понял, что часто не могу определить для себя, каков именно результат, и поэтому теряюсь между разными задачами.
Сейчас это не так, ибо каждый день, каждую неделю у меня перед глазами вектор, который я себе задаю.
Если быть точным, я использую мойТиниТодо .
Очень удобный инструмент, гибкий, как Excel, и устанавливается на любой хостинг.
Я создаю столько вкладок, сколько хочу - для идей, для задач перед уходом с работы, на месяц - и каждый раз держу вкладку с этой штукой открытой.
Это позволяет мне оставаться на цели.
Такой простой случай, но у меня он работает уже два года, и плюс работает у ряда моих коллег (люди брали другие инструменты, но суть - видеть перед глазами список дел - осталась та же ).
А теперь о том, как переориентировать процессуально ориентированных людей на результат (вернее, на методы достижения результатов, живых и реальных).
Также несколько случаев из жизни.
Почти все они касаются программистов (я работаю с несколькими десятками программистов через цепочку людей или напрямую; всего в проектах задействовано сто человек разных специальностей).
Как обращаться с людьми
1.РЕРО
РЭРО — принцип «выпускай раньше, выпускай часто» (выпускай раньше, выпускай часто).Оно должно проходить через весь ваш мыслительный процесс.
Потому что в голове назревают идеи, от уровня «сделать мега-дорогой дизайн, суперпроект и выложить все сразу, с правильной архитектурой» до уровня «самозагрузка максимально просто и дешево», как можно скорее выйти на рынок с MVP, четко и быстро собирать обратную связь, развиваться, выделять точки для рефакторинга и реструктуризации архитектуры согласно собранным живым данным и реальным требованиям бизнеса».
А все остальные — программисты, дизайнеры — выстраиваются внутри вас в цепочку, и работают наиболее эффективно тогда, когда вы эффективно мыслите и видите весь процесс.
Пример из жизни.
Теперь вместо реализации мегасложного отчета в ERP мы сначала делаем простую версию и собираем статистику использования.
Скорость релизов в отдельных проектах выросла до 10 раз.
Простая постановка задачи (об этом будет сказано выше) с максимизацией ограничений (делайте конкретно, а не универсально, не делайте 100500 фильтров или универсальных, используйте готовый бутстрап-макет вместо рендеринга 10 дизайнов и т.д. ) обеспечит как программистам, так и всем остальным участникам оценку задач за приемлемый период времени, и это позволит добиться результата.
2. Бонус от выполнения задания
Мне не удалось наладить контакт ни с одним программистом по части реализации.Потом я начал выделять бонусы конкретно за реализованный функционал.
Бонус простой, понятный, понятный, как оплата за продажу копии коробочного ПО.
И уже через неделю коллеги начали спрашивать меня, почему мой программист пристает к ним по поводу реализации функционала (это обычный кросс-проектный компонент).
Собственно, начали это реализовывать, программист стал добиваться результатов и тем самым зарабатывать бонус.
Я горжусь им.
3. Изложение, не вызывающее вопросов + разделение задач
Обычно я стараюсь ставить задачи типа олимпиадных.Суть проблемы, история пользователей, ввод, вывод, данные для проверки.
Конечно, некоторым это не нужно, но если поставить конечную цель и показать, как должен выглядеть и работать финальный релиз, есть большая вероятность получить то, что вам нужно.
Отдельно скажу, что вы сами (или ваши руководители) должны разбить задачу на части с релизом 1-2 дня.
Единственный путь.
И тогда вы сможете предоставлять релизы типа Badu (5 релизов в день? или сколько у ребят, давно не искал).
Конкретный пример из жизни.
Необходимо произвести сложную интеграцию двух исторически хаотично связанных клиентских баз.
Описываю только основные механизмы со схемы (дополнения со стороны CRM), имея в виду архитектуру всей системы.
Если описать всю систему подключения клиентов (отели, объединение отелей в сеть, сети в суперсеть, со сложными ACL), то написание решения займет месяц.
А простые улучшения для решения части проблемы (отели и сети и простой ACL) займут пару дней, и программист увидит их выполненными.
Потому что задача разбита грамотно.
4. Предварительная проверка рынка
Это очень хорошо описано в одном из курсов ребят из Stratoplan (платный пост, инфо 100%).Суть проста: не тратьте более 1000 долларов на тестирование рыночной идеи.
Лучше всего просто рассылать целевой спам клиентам и смотреть, сколько людей оставляют электронные письма, ожидая релиза этой функции.
Когда вы объясняете людям эту задачу, вам нужно донести, что проверка должна быть максимально простой и быстрой.
Если возможно, потратьте один день на разработку.
Скажем, на то, чтобы закодировать что-то, что потом не понадобится, уходит месяц.
И программисты — а они, как правило, умные люди — поймут, что лучше сделать что-то за один день, чтобы проверить идею, чем потратить месяц на то, что потом не будет востребовано.
Работает.
5. Объяснение сути вещей
Иногда встречаются люди, которые решают проблемы.Я сам такой, считаю, что это очень важное качество и для программиста, и для руководителя проекта.
Человеку нравится решать чужие проблемы.
Итак, если вы объясните суть проблемы в задачах (см.
выше), зачастую программист может предложить более простое и быстрое решение, чем вы даже могли бы придумать.
Потому что он в теме, в коде, в архитектуре и понимает технические возможности проекта лучше вас.
Пример из жизни.
Объясняю задачу соединения двух хаотичных баз и что нужно получить.
Сам программист (!красивый и умный) предлагает разные отчеты и фильтры, делает выводы из этих отчетов.
И вся картина как на ладони.
Это позволило нам получить представление о том, как должна быть структурирована система.
6. Воспроизводимые (многоразовые) решения
У нас есть группа гостиничных проектов.И там для учета отелей я поставил задачу сделать специальный счетчик, который бы принимал ID отеля, вошедшего в систему.
И каждый программист на проекте (я руковожу лишь частью гостиничных проектов и инфраструктуры) с радостью установил счетчик, вместо того, чтобы сделать свой.
Если вы бывший программист, вы понимаете силу повторного использования.
Невозможно передать тот восторг, когда новый функционал в системе собирается из уже написанных блоков.
Если нет, то поверьте, если вы предложите решение, которое потом будет тиражироваться и масштабироваться, программист будет рад довести его до конца, ведь люди любят повторное использование, и когда они используют продукты своего творчества.
Что дальше?
В комментарии приглашаю опытных коллег, которые не стесняются делиться своим опытом и рассказывать об успешных случаях из своей жизни.Теги: #процессоры #результаты #как остановить %s и начать работать #GTD
-
Топ-10 Вирусных Видео, Февраль 2010 Г.
19 Oct, 24 -
Релиз Livestreet 0.5
19 Oct, 24 -
Коллекция Диаграмм Классификации Баз Данных
19 Oct, 24 -
Разработка Драйвера Minifilter
19 Oct, 24
