Стратегия важнее тактики
Стратегические просчеты невозможно компенсировать тактическими успехами.
«О войне», фон Клаузевиц
Это же можно сказать и про проект. Выбрали десктопное приложение вместо того, чтобы писать под Web — огромный просчет. Выбрали неверную сферу и под нее угрохали огромное количество средств — никак не реализовать. Выбрали неправильный приоритет по функционалу на месяц, конкурент вас обогнал — опять же, потеря может быть критической. Выбрали неверную технологию — вместо быстрого языка PHP писать на «правильном» типа Ява — опять же потеряли стартовую скорость, еще не выйдя на орбиту.
Кстати, стратегия является отличной защитой от всяких умников, которые будут копировать ваш проект.
Зарплата сотрудника должна быть плавающей
Перед сотрудником должны стоять цели, из семи слов, с измеряемыми цифровыми показателями. Как говорил Друкер, всем, что можно измерить, можно управлять. Таким образом можно поставить зависимость эффективности сотрудника от конкретных задач, и избавиться от проблемы, что сотрудники пришли в 9, ушли в 18, хотя работа не доделана. Хочешь получать много — доводи задачи до конца, хочешь еще больше — работай эффективно и опять же немало. Хочешь ничего не получать — ну ок, сиди в Фейсбуке.
У каждого сотрудника есть набор показателей — семь слов с цифровыми показателями. ЗП завязана на значения этих показателей. Вот и все.
К примеру, это суперпозиция 10 показателей у программиста и его руководителя — стабильность проекта, удовлетворение пользователей. Делая вклад того или иного показателя больше или меньше, вы указываете программисту (и его руководителю), на что сделать упор. А люди видят, что их оценивают по результату.
Разумеется, должен быть гарантированный оклад, ниже которого человек не получит.
Руководитель должен знать цену своей минуты
Руководитель должен знать, сколько стоит его минута. Как в прямом отношении, в пересчете из расчета его дохода, так и в косвенном — как говорят в экономике, стоимость упущенной возможности, которая появляется, если руководитель занимается не тем, чем нужно.
Станьте своим клиентом
Самое важное в управлении проектом, понимание конечного пользователя. Если вы не умеете мыслить, вживаться в роль своего пользователя, все остальное будет неверным: за неправильным выбранным функционалом и неверным прототипом интерфейса последуют потерянные часы и деньги в виде работы дизайнеров, программистов, тестировщиков и других специалистов. Заметьте — я не говорю, что нужно слушать своих пользователей, ибо они — не профессионалы в разработке проектов. Суть именно в том, чтобы погрузиться в роль своего пользователя, при этом оставаясь профессионалом в разработке проекта, и сделать удобный интерфейс. Ибо, как говорил Форд — если бы я слушал своих клиентов, то я вряд ли должен был бы им дать что-то большее, чем немного более быстрая и выносливая лошадь.
Знание шкуры конечного пользователя позволяет видеть, что важно делать сейчас и как именно это нужно сделать, а что можно не делать вообще, либо отложить надолго.
Думайте о рисках заранее
На все должен быть план, чтобы когда бяка случается, вы не тратили время на удивление, а действовали по накатанной четко и спокойно.
Из моего опыта — это, к примеру, когда увольняется один из ключевых сотрудников. Первые пару лет работы руководителем я был в шоке, дальше я уже просто измерял, насколько мой риск точно просчитан в плане процентов и временных рамок.
Быстро и просто — значит дешево и сердито
Потапенко прописывает бизнес-процессы алгоритмами, как я понял, на уровне учебника восьмого класса по информатике. Я с ним согласен — пока что известные мне процессы вполне ложатся в классические блок-схемы с циклом и условным оператором. Все сложное, за редким исключением — от лукавого
Далее, Потапенко расписывает в бизнес-процессах все до деталей, вплоть до того, в какой момент кассир должен улыбаться клиенту.
И на одном семинаре, где он аргументированно критикует CEO, звучит его фраза — народ в РФ вымирает, кадров не найти, так чего же вы рассчитываете на умных сотрудников, а обходит вас МакДональдс, заточенный под биороботов?
Плюс говорит на Селигере, что если вы делаете сетевой объект — вы сразу должны делать первый же объект по сетевому принципу. При этом выносить (принцип из программирования SPOT/DRY) в одну точку что-то дорогое и делать дешевым за счет аутсорса — например, кухню.
Это отлично ложится в разработку стартапов. Люди начинают делать продукт — не важно, будь это новая СУБД, интернет-магазин по продаже чесалок для жопы или автоматизация финансовых потоков. Умные и уверенные в своем профессионализме, они думают, что набрасываемые статичные прототипы и user stories — это замена живым данным и вживанию в роль пользователя. Сразу делается на бюджет в пару миллионов за полгода большое, тупое, никому не нужное говно, которое тонет в очередной раз.
Вопрос — в чем же дело, почему не работают крутые методологии, когда все по-взрослому, и профессионалы работают вроде бы?
Ответ — нельзя разработать сложный проект без живых данных, без обратной связи на живых данных. Любой сложный проект всегда делается с ошибкой, чем сложнее первая версия — тем дольше делать и тем выше ошибка. Значит, нужно минимизировать сложность и тем самым уменьшить ошибку.
В итоге говномонстров обходят умные ребята типа 37signals, которые делают минимум функционала, смотрят глазами конечных пользователей, тут же выкатывают его пользователям и по-умному собирают обратную связь.
То есть чем проще процесс разработки, чем быстрее есть выкатывание версий, чем больше первая итерация похожа на все дальнейшие — тем обкатанее будет продукт. Как сетевой магазин, первая итерация должна иметь вход — это первоначальные домыслы, как должно выглядеть, и выходную информацию — разницу между домыслами и реальностью, на живых данных.
Почему живые данные и работающий прототип (первые версии проекта). Потому что как только в любую красивую веб-верстку вместо ispum dolor вставить разноцветных текстов по 100 кб, которые будет вставлять клиент, а также 20 пунктов меню — все становится по-другому.
Как только вместо кликабельных HTML из Акзура вы видите работающий поисковик с таблицей, в которой выводится 50000 записей, сразу становится понятно, как и что нужно фильтровать и какие сортировки добавить. Этого НЕЛЬЗЯ предусмотреть на бумаге. Человеческий мозг слишком слаб, чтобы моделировать такие сущности.
Нет, конечно, я не отрицаю, можно и успешно делать большие проекты, применять RUP, и быть успешным. Но если мы говорим про молодую отрасль — управление проектам в IT, как правило — в Web, я бы сильно усомнился, что целесообразно действовать традиционным подходом (даже с Agile, но без микроитераций, быстрых версий и погружения в роль пользователя).
Да и в больших проектах — помню, видел в какой-то статье следующее. Однажды строители аэропорта построили модель неподалеку. Прототип. Туда пустили живых людей, изучали, как они ходят, как себя ведут. Сами инженеры ходили, изучали плюсы и минусы разных вариантов. Как итог — сдали проект в срок и сократили бюджет на порядок, в отличие от аналогичных строек, где все делается большим и сложным сразу (и получаются угребищные, всем нам известные аэропорты).
Посмотрите ролик в тему, как строят самолет на лету. Очень точно отражает идею.
Еще одна идея из Потапенко — всеобщая стандартизация и прозрачность каждого действия людей. А-ля сотрудники-биороботы. Не буду отрицать, что стандарты кодирования, оформления статей в вики, обязательных комментов к коммитам и другие могут сэкономить вам тысячи час в разных ситуациях.
Стартап — это бизнес
Любой стартап, как это не прискорбно, это бизнес. Если не брать успешные единицы, в проекте немаловажной является минимизация издержек. Это же, кстати говоря, относится и к скорости. Хотите писать таск-менеджер на С++, с крутой ООП архитектурой, чтобы сразу выдерживал миллион запросов в секунду — честь вам и хвала. При этом чтобы люди сидели в одной комнате в элитном бизнес-центре, все было по самым крутым методологиям, все стены обвешаны UML.
Но не удивлюсь, если такую команду, которая уже изначальна будет должна инвестор не один миллион, обойдет парочка друзей, скопивших на халтурах полмиллиона, и выпускающая каждую неделю новую версию таск-менеджера на C#. При этом имеющую удаленных программистов из всех регионов РФ и Украины. Потом уже эти люди заработают денег и перепишут с нуля. Но первый этап — взлететь, и взлететь быстро, за счет постоянной обратной связи от пользователей, быстрого выкатывания простых решений.
Применять идеи из других сфер
Потапенко спрашивает зал: как вы думаете, какая самая крупная розничная сеть? МакДональдс? Валлмарт?
Ответ неверный! Правильный ответ — католическая церковь!
Не нужно стесняться смотреть, как устроены схожие по устройству процессы, изобретения, решения задач в других сферах. И тем более не следует думать, что задача, которая сейчас стоит и кажется нерешаемой, не вставала еще ни перед кем. Всегда полезно мыслить аналогиями. Это часто помогает упростить исходную задачу и сделать ее хотя бы отчасти.
Много работать
Это тупо, но — нужно много работать. Лично я работаю в среднем по 12 часов в день, 6 дней в неделю. Если работаешь эффективно, при этом у тебя резко растет количество результатов в единицу времени. Затем придет и качество.
Если хочется машину — выбросите эту идею, лучше снять квартиру около работы (или офис около дома, если свой бизнес). Машина — актив, который падает в цене. А ваше время, просераемое в пробках — это невозобновимый ресурс, стоимость которого, если вы знаете свою минуту, может стократ превышать за год мнимый «комфорт» от машины.
А вот когда будет лишние пара миллионов — можно и машину купить. ИМХО, разумеется.
Аутсорс дорогих участков процесса
Согласитесь — лучше пару раз в месяц дернуть суперспеца по сдельной работе, чем держать такого за бешеный оклад и не знать, как его загрузить. Поэтому дорогие аспекты работ нужно выносить на аутсорс и группировать (в сетях обычно выносят кухню — Single point of truth из программирования работает и тут).
Заключение
Напишите ваш опыт применения принципов из других сфер в управлении проектами в комментарии.
* . ради краткости порой указывается просто как XT и LX, опуская приставку Deore. 
Вот уже несколько лет мне приходится иметь дело с интернет-магазинами. Причем с самых разных сторон: и со стороны покупателей, и со стороны разработчиков, и со стороны интернет-рекламы, и со стороны b2b-сервиса, клиентами которого являются опять же интернет-магазины. Следствием такой плотной работы с онлайн-ритейлом явился определенный набор наблюдений и замечаний, иногда не совсем очевидных и спорных. 