Как вы управляете производительностью в небольшой команде стартапа?

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

Управление проектом требует времени, независимо от того, какой у вас метод. Чем больше у вас задач, тем больше времени это занимает и тем больше это раздражает. Неважно, сбрасываете ли вы данные в Microsoft Project Server или на картонную диаграмму Канбан. Данные есть, их нужно обрабатывать. Нет такой вещи, как: «Слишком много работы, что я не могу записать, что нужно сделать».

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

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

я не могу просто поставить задачу и дать ей временные рамки.

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

Как не дать людям не работать, когда они должны? Скажи им. Им платят за работу. 14 лет работы над Duke Nukem, возможно, тоже достойны награды, но большинство стартапов не могут себе этого позволить.

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

Во-первых, не беспокойтесь о том, что команда делает каждую минуту дня. Если вы, программисты, проводите «руки на клавиатуре» три-четыре часа в обычный рабочий день, это высокая производительность. Существует миф, что 12-часовой рабочий день семь дней в неделю более продуктивен, чем восьмичасовой рабочий день в стабильном и устойчивом темпе. Сосредоточьтесь на результатах, а не на том, что Джо кодирует 30 минут, FB 30, кодирует 30. Сосредоточьтесь на том, что сделано.

Agile-практики работают благодаря трём вещам: ясности бэклога, подотчетности команды и измеримому прогрессу.

Ясность бэклога: вам нужно выкроить тайм-аут с основателем, чтобы убедиться, что то, над чем вы работаете, является правильным. Это можно сделать довольно легко и за небольшие отрезки времени, используя решение для групповой подотчетности.

Ответственность команды. Многие стартапы считают, что Scrum — это слишком сложный процесс. Вещи меняются очень быстро, и люди часто очень специализированы. Вы, вероятно, добьетесь гораздо большего успеха с простой доской Kanban с ограничениями Work in Process.

Канбан-доска представляет собой упорядоченный список работ, которые необходимо выполнить. Любая работа, которая должна быть сделана, размещается здесь. Даже такие вещи, как «заказать новый стол для новичка». Нет времени на работу. Вместо этого люди берут верхушку бэклога и работают над ней. Вы устанавливаете лимиты работы в процессе, чтобы люди не работали над несколькими проектами одновременно, и даже не поощряете выполнение задач несколькими людьми. Когда у основателя есть несколько минут, перетащите его к доске, чтобы проверить порядок вещей и попросить что-нибудь новое. Устраивайте ежедневные стендапы, как в Scrum, чтобы команда могла рассказать о проделанной работе и планах. Еженедельно анализируйте, что сделано.

Измеримый прогресс Единственный способ по-настоящему измерить — это поставить работающее и протестированное программное обеспечение. Постарайтесь как можно скорее перейти к среде непрерывной сборки. Когда кто-то проверяет код, вы сразу узнаете, сработал он или нет, основываясь на том, убивает ли он сборку. По крайней мере, постарайтесь иметь ежемесячные вехи, когда продукт проходит сборку и демонстрируется.

Дополнительные советы по agile-проектам можно найти на форуме Project Management Stack Exchange.

По тому, как вы описываете ситуацию, я понимаю, что ваша самооценка правильная - вам нужна дополнительная поддержка. Во-первых, вам нужна подготовка. Есть много курсов, где-то между $ 500 и $ 5000. Книга первая.

Во-вторых, вы хотите, чтобы все было просто. Scrum может быть довольно сложным, поэтому уменьшите количество вещей . Предлагаю начать только со следующего:

• Сохраните что-то похожее на Scrum Sprint, но упростите. Согласуйте цель с командой, заставьте их придумать, чего они хотят достичь к концу недели. Это поможет им самостоятельно понять, над чем работать, если одно задание будет выполнено раньше срока . Лучше всего выяснить, чего добиться на следующей неделе, к концу четверга.

• Держите ежедневный стендап, но пусть он будет коротким. Никогда не позволяйте ему длиться более 10 минут, иначе людям станет скучно, и они саботируют собрание. Если нужно обсудить что-то еще, договоритесь о последующем совещании, чтобы обсудить это сразу после стендапа — только люди, имеющие отношение к конкретному обсуждению, должны присоединиться к последующему совещанию, и это может означать, что даже вам не нужно присутствовать. Стендап должен быть отчетом о состоянии команды (а не руководителю группы) и о том, что каждый планирует сделать в течение дня , чтобы люди могли лучше координировать свою работу .

Помните: вы не хотите говорить им, над чем работать — вы хотите, чтобы они поняли, над чем работать. Вы не хотите координировать их работу — вы хотите, чтобы они координировали свою работу друг с другом.

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

Что касается Facebook/Twitter, используйте заимствованный авторитет, если можете. Пусть начальник скажет команде, что он заметил большой трафик в социальных сетях и что он доволен тем, что люди время от времени пользуются этими сервисами во время перерывов или когда это необходимо для работы, но он был бы признателен, если бы привилегиями не злоупотребляли, поэтому его не заставляют блокировать услуги.