Управление небольшой командой

Это дополнение к ответу на вопрос выше. Так как похожий вопрос на этот есть в вопросах. Да и наверное тут я не сказал про "наш дискорд канал". Но давайте немного разберём путь проекта, когда ко мне приходит заказ. Не берём работу по обсуждению, выяснению бизнес требований и так далее. Задача понятна, пора делать. Что происходит дальше?

Раз задача понятна, значит я составил список необходимых специалистов. Обычно в процессе обсуждения проекта я уже знаю, кто его будет делать. Все условия обговорены и так далее. Дальше у нас идёт процесс разработки. Первое что появляется — это таблица проекта. Посмотреть её можно по ссылке. Иногда она внутренняя, иногда она для заказчика. Тут отслеживается всё. Дедлайны, итерации, список задач. Ещё обычно добавляются колонки с ресурсами задач и вопросами. Общей быстрее всего она становится для конфликтных заказчиков, чтобы просто показать что "у нас все ходы записаны". Но так же это самый точный план проекта и отображение его хода.

Первый лист — это у нас диаграмма Ганта или роадмап. Тут мы взяли ТЗ, декомпозировали его на таски, оценили сроки, составили план проекта. Если что-то смещается и съезжает — он корректируется.

Второй лист — это итерации. И это удивительная штука, что многие очень странно сдают контент. Я очень часто и подолгу объясняю заказчикам, что контент можно крутить — вечность. Работа людей — стоит денег. Комментарии даёте вы, а не мы сами из головы придумываем что делать. Поэтому число итераций по любой работе в рамках конкретного бюджета — ограничено. Мне кажется заказчики просто привыкают к тому, что есть фрилансеры с низкой самооценкой, которые готовы пол года перерисовывать одно и тоже. Я против такого и за честную оплачиваемую работу. Итераций может быть несколько, требования могут меняться, процесс может быть херовый (в зависимости от клиента), но всегда ограниченный во времени и в деньгах.

Дальше в моей специфике идёт то, что либо каждый исполнитель отдельный таск борд делает себе. Либо мы делаем таскборд по проекту. Но последнее скорее редкость, так как у меня специфичные проекты не требующие в среднем несколько разработчиков на одном стеке технологий. А когда это не требуется, то и общий таскборд не особо нужен. Так как задачи условно независимы. Главное понимать в логику моков и т.п. Плюс общий дискорд чат по проекту для обсуждения задач.

В трелло у нас всегда стандартные ToDo -> InProgress -> Review -> Done. Так как я идеологически не вижу смысла "стоять у кого-то над душой" и пристально следить "а работает ли человек". InProgress — это графа скорее по привычке. Я работаю не по T&M, а с фиксированными бюджетами именно по той причине, что мне важен только результат. Ничего не делал человек неделю, а потом за день всё сделано и качественно — отлично. В графе ревью задача улетает на согласование с клиентом, Done значит что она сделана и не вернётся, так как у меня или менеджера есть "да" от клиента. А если есть да, то это новая задача и возможно новый бюджет.

Вообще T&M я считаю злом. Систему на той же работе тоже не совсем удобной и корректной. Есть самый простой путь. Есть бизнес задача, есть бюджет на эту задачу. Если бюджет согласован, сроки согласованы, то нет никакой разницы сколько человек потратил часов на её выполнение. Сидел днём за компом или ушёл по своим делам/в кино. Сроки соблюдены, задача выполнена в бюджет. Всё остальное неважно.

Но это ремарка про аутсорс проекты. Управление небольшой инди командой строится немного иначе, так как это самостоятельный сыгранный юнит должен быть с "неопределённым" заранее результатом. И процессы разработки продуктов отличаются очень сильно. Хотя продукты можно разрабатывать так же, да и игры. Просто не особо эффективно. Чисто из-за скорости коммуникации на каждую итерацию или версию продукта. Если кому-то интересно, то могу написать свои мысли на счёт небольших инди команд "как бы я строил процесс". Ну как всегда, валюта у нас 🔥.

Напоминаю как всегда, что вопросы можно задавать тут. Любые на любую тему.

#вопросы