Любая команда, желающая наладить рабочий процесс, рано или поздно сталкивается с необходимостью установления определенных правил и договоренностей. Как показывает практика, на начальных этапах работа команды строится на условных соглашениях, которые каждый обязуется выполнять. И даже если все участники ответственны и своевременно справляются со своими обязанностями, процесс работы со временем все равно начинает страдать. Почему возникают подобные проблемы, и как с ними справляется наша команда? Предлагаем узнать это, заглянув по ту сторону стартапа.
Этап 1. Подготовительный.
На первом этапе (2 года назад) мы вообще не думали о том, что наша работа должна строиьтся каким-либо определенным образом. На тот момент мечты и завышенные ожидания перевешивали реальное положение дел, поэтому мы действовали строго интуитивно – каждый должен сделать свою часть работы как можно быстрее, а все остальное образуется само собой. Мы не думали о последствиях тех или иных действий, не старались предусмотреть возможных ошибок и каждый раз, набив очередную шишку, погружались в состояние фрустрации. Нам казалось, что мы совершенно не способны взаимодействовать друг с другом.
Этап 2. Ознакомительный.
Шло время, и рабочий процесс становился менее хаотичным, хотя продуктивность все еще оставляла желать лучшего: срывались сроки, выполнялись ничтожно малые объемы работ, и, что самое страшное, понимание этого приходило не сразу. Проблема заключалась в том, что у нас не было никакой возможности объективно оценить нашу продуктивность, т.к. все мы полагались на свою память и ощущения.
Пришло время что-то менять, и мы начали задумываться о методах командной работы. Первым делом было решено куда-то записывать и распределять между собой задачи и подзадачи. Для этих целей мы начали использовать российский планировщик задач teamer.
Он оказался достаточно удобным, однако, непонятно почему наша активность там очень быстро заглохла, и мы вернулись к прежнему образу жизни (вся работа проходила в чате Skype’a, чередуясь с редкими встречами). Такая простая и, в целом, неэффективная методология спустя некоторое время все же привела нас к запуску проекта.
Этап 3. Переломный
Запуск принес с собой большое количество проблем, и стало необходимым:
– вовремя обрабатывать и реагировать на обратную связь;
– вести учет дельных предложений по улучшению сервиса;
– контролировать и исправлять найденные в сервисе баги;
– синхронизировать действия внутри команды;
– устанавливать реальные сроки для той или иной задачи;
– оценивать объемы работ для грамотного их исполнения;
Тогда чат в Skype перестал приносить практическую пользу, и мы стали очень часто созваниваться. Так мы прожили первые полгода после запуска проекта. Спустя время, будучи на пороге создания второй версии нашего сервиса, мы решили, что рабочий процесс требует гораздо больших изменений. К этому нас также подтолкнул наш новый партнер, являющийся также инвестором.
Teambox
Именно Teambox стал сервисом, где по сей день организуются основные рабочие процессы команды. В Teambox’e мы используем лишь 2 инструмента: Задачи и Обсуждения.
Наша структура инструмента «Задачи»
– дизайн;
– верстка;
– программинг;
– функционал, который поможет улучшить сервис;
– ежедневные отчеты о проделанной работе;
В каждом из разделов публикуется список необходимых задач, для каждой из которых по возможности устанавливается срок, приоритет и ведется дополнительное обсуждение. Таким образом, мы не тратим время на лишние разговоры, а всегда знаем, что необходимо делать следующим.
Наша структура инструмента «Обсуждения»
– идеи (обсуждаются любые идеи, самые ценные из которых переносятся в список задач);
– дизайн (обсуждаются любые моменты/пожелания по дизайну, постятся скриншоты/примеры из других сервисов);
– презентации (о них речь пойдет далее);
– командные встречи (коллективно обсуждается время и день общих созвонов);
GitHub
На данный момент GitHub выполняет не только функцию репозитория для хранения кода, но используется еще и в качестве баг-трекера. Создать «тикет» и назначить ответственного занимает считанные секунды.
Skype-конференции
Еще на начальных этапах работы с инвестором мы договорились о том, что обязательно должны созваниваться один раз в неделю и неопределенное количество раз по экстренным случаям или же срочным вопросам.
Еженедельный созвон представляет собой отчет одного из участников команды по той части работы, которую он проводит. Обычно отчет делится на две части:
1. Что было сделано за прошедший период;
2. Над чем участник команды собирается работать в ближайшее время;
После выступления по каждой из частей инвестор и другие члены команды задают свои вопросы, если таковые возникают. Таким образом, мы всегда владеем актуальной информацией о процессе работы над проектом.
Так как в команде нас всего трое (дизайнер, верстальщик, программист), то 4-ый по счету созвон мы делаем общим, где устраиваем небольшой психологический сеанс, а именно выплескиваем все свои чувства и эмоции касательно работы над проектом, обсуждаем насущные проблемы и вопросы. Это помогает нам «выпустить пар» и двигаться дальше в привычном режиме.
Приоритет реализуемого функционала
Со временем у нас накопилось достаточно много различных фич, способных по нашему мнению улучшить сервис. Но мы стараемся придерживаться правила: «Чем проще, тем лучше», поэтому все идеи касающиеся новых функций проходят жесткий отбор.
Каждая идея оценивается по 4-ем критериям/целям проекта (выставляются оценки от 1 до 10):
– поможет ли данный функционал привлечь пользователей?;
– насколько он удовлетворит потребности пользователей?;
– насколько он поможет удержать пользователя на сайте?;
– сложность реализации данного функционала;
Заключение
Именно так обстоят дела в нашей команде на сегодняшний день, хотя мы осознаем, что нам есть над чем работать в плане улучшения взаимодействия. Подводя итог, можем сказать, что процессы взаимодействия в команде должны меняться естественным образом. Изменения нужны тогда, когда вся команда испытывает в них потребность. В другом случае использование различных методов работы будет не до конца осознанным, что может не только не улучшить, но и ухудшить результат вашей деятельности.
Надеемся, что данный материал оказался для вас полезным. Любые предложения, а также обмен собственным опытом приветствуются.
Автор: fantique
