Весь свой опыт управления проектами и решения проблем я приобрёл из того, что ресурсов всегда не хватало, и нужно было шевелить мозгами и задницей чтобы достигать целей в рамках жёсткой конкуренции. Но ошибочно считать, что ресурсов реально не хватает везде и всегда: стартапы, госзаказы, подъёмные инвестиции в новые подразделения и так далее – есть масса противоположных случаев, когда ресурсов вполне достаточно с избытком. Когда я некоторое время работал в Москве, там была группа разработчиков в 22 человека – штатно, в офисе, и это только программисты! Никто особо не жаловался на нехватку людей.
Но в моей профильной области (сайты и веб-проекты) эта ситуация скорее обусловлена рынком, который мучительно развивался с полного нуля в 1998, к 2007 году достиг пика развития (какой у вас бюджет на сайт? меньше 15 тысяч долларов? идите нафиг), свалился со всеми в 2008 и теперь в него открыта дорога всем, кто работает по принципу “как можно дешевле и как можно быстрее”. В ситуациях, когда до 98% дохода отводится на зарплатный фонд – трудно ожидать эластичности штата.
Как управлять проектом при недостатке ресурсов? Есть несколько принципиальных моментов:
Наиболее глупое, что вы можете сделать, это выкинуть все методики и начать “рвать жопу”.
Я в своё время ушёл из одной такой компании – это было ещё до кризиса. Возможно, та компания таки окончательно порвала себе упомянутую “ж”, потому что сейчас вместо крупных проектов она занимается предоставлением небольших сопутствующих услуг владельцам существующих сайтов. Человек, который призывает вас спешить и суетиться – провокатор. Не поддавайтесь.
Все методики написаны не от хорошей жизни. Они все написаны с целью выйграть в конкурентной борьбе, а значит – достичь большего при меньших ресурсах. Например, популярный SCRUM предписывает сконцентрироваться на кратком списке актуальных дел, безжалостно выкинув в общую кучу (backlog) абсолютно все остальные задачи – и ни в коем случае не планировать и не расставлять им приоритеты раньше времени. Потому что завтра всё изменится. Это ли не отражение реальных дел в небольших IT-компаниях?
Чем труднее у вас ситуация, тем жёстче вы должны следовать выбранной методике. Если она, разумеется, подобрана правильно.
Самое главное зло при недостатке ресурсов – это человек, который об этом не в курсе.
Это может быть, например, ваш начальник или инвестор. И ещё полбеды, когда он знает, но не хочет признавать этот факт. Гораздо хуже ситуация – через полгода работы над проектом услышать “а что ж ты раньше не сказал, что надо в 5 раз больше людей? Где я теперь найду такие инвестиции?”.. Как-будто полгода назад он бы вынул их из кармана. Но неважно, провокация это или реальная неинформированность. Помните: информация в багтрекере, ясная и понятная для вас, всегда будет филькиной грамотой для стороннего человека. Документируйте все цифры и расчёты, и регулярно отправляйте “наверх”.
Второе – это менеджеры среднего звена, люди, так или иначе желающие запустить лапу в казённые ресурсы. Я регулярно провожу эксперименты: собираю несколько человек вместе, показываю им багтрекер со списком в 150-200 задач (на одного исполнителя), и предлагаю им договориться между собой о приоритетах. Моментально несколько десятков задач улетают в конец очереди, картина проясняется, и начинается продуктивная работа.
Третье – это непосредственно разработчики. Осведомлённость этих людей о происходящем вокруг всегда будет крайне низкая, даже если их каждое утро и вечер собирать на 5-минутные стэндап-митинги. Изредка 2-3 человека благодаря схожим задачам и совместным перекурам устанавливают между собой контакт и понимают вектор движения друг друга. Всех остальных нужно информировать и направлять принудительно, не надеясь ни на какое волшебное информационное поле.
Планирование проектов или этапов тоже по сути противоположное:
Планируйте не то, что хотелось бы сделать, а то, без чего нельзя обойтись.
Так делают некоторые спортивные суперкары – и получается неплохо. Если вы хотите запихать в этап проекта всё больше и больше фич – вы обречены на провал. Не начинайте с чистого листа, на который будут записываться задачи. Наоборот, начните со списка задач, и безжалостно выкидывайте из них все несрочные. Недостаток ресурсов всегда приводит к жертвам: либо вы пожертвуете фичами, либо багами, либо своей компанией (если попытаетесь успеть и то и другое). Выбирайте.
Умение пожертвовать ненужными сейчас вещами – крайне важное качество любого менеджера. Очень просто планировать какие-то различные фичи и решение каких-то багов. Но попробуйте задать вопрос в лоб: какие проблемы для нас сейчас наиболее критичны? Это лучший способ посеять панику в умах. В лучшем случае вы получите список из 3-5 пунктов. В большинстве случаев выяснится, что перед вами в данный момент стоит лишь одна реальная проблема.
Что касается непосредственно самого процесса разработки, то тут, как говорилось в одном известном фильме
У вас уже не будет никакого “потом”.
Всё, что вы пишете, вы пишете на века. У вас уже не будет никакого code review и никакого рефакторинга. Хотя возможно он и будет, но через столько лет, что вы уже давно перейдёте на другую должность или в другую компанию. Поэтому прислушайтесь к рекомендации компании Apple и делайте t-y-p-e s-l-o-w-l-y. Не в смысле медленно набирайте код, а в смысле – вдумчиво: то, что вы наберёте сейчас, вам уже некогда будет переписать.
Задавить в себе принцип “быстренько попробую, потом нормально перепишу” бывает крайне тяжело. Считайте, что вы никогда это не перепишете, а ваш баг будет годами болтаться в багтрекере и портить настроение следующему поколению.
Используйте таск-менеджер с очередью задач.
Никакой таск-менеджер не может считаться достойным, если он не имеет инструментов для быстрой сортировки задач тупым вертикальным списком. Единственный инструмент управления – это очередь. Никакой план, никакая диаграмма Ганта и никакие липкие листочки не имеют права на жизнь. Только одна простая очередь, понятно и недвусмысленно говорящая ЧТО сейчас надо делать, а что – потом, достойна вашего внимания.
Единственный инструмент, где это сделано естественным образом – это Acunote: можно просто двигать задачи мышкой вверх-вниз. Популярный Mantis в этом плане безжалостен: он позволит создать хоть десять “безотлагательных” задач на одного человека, и даже не пикнет. О популярных отечественных инструментах для планирования – даже говорить не хочется.
Завтра – это вчерашнее сегодня.
Часто можно услышать: когда наши продажи поднимутся, то это будет реальный видимый результат – вот тогда можно и премии раздать, и людей новых нанять. На самом деле любому, кто в институте не прогуливал экономику, известно что продажи – штука весьма неэластичная и инерционная. Они не вырастут за ночь. Они скорее всего значительно не вырастут за месяц. Обычно на устоявшемся рынке нет такого количества потребителей, чтоб так колебать спрос. И даже если продажи вырастут через три месяца, всё равно любой здравомыслящий предприниматель ещё подождёт какое-то время, чтобы увидеть стабильность эффекта. Поэтому тот объём ресурсов, который у вас сейчас есть, будет ещё очень долго: трезво оцените их, прежде чем браться за дело.