Как я учитываю задачи у себя в команде.
Меня зовут Михаил Протасов. Я индивидуальный предприниматель, у меня на данный момент 9 фулл тайм сотрудников. Мы автоматизируем управление персоналом для крупных компаний. Среди моих клиентов: Газпром, Центральный Банк России, Интер РАО ЕЭС, РосГосСтрах, АльфаСтрахование, Московский Кредитный Банк, Окей, Медси и многие другие. Я работаю в этой области с 2007 года, а свой бизнес начал в январе 2019.
Меня всегда интересовали вопросы самоорганизации, организации работы команды и учета личных и командных задач. На протяжении своей карьеры я постоянно обучался этому, читал книги, проходил тренинги, пробовал различную методологию, программное обеспечение, обучал и консультировал других людей. В моей команде мы используем собственную программную разработку для учета командных задач. Мы ее постоянно развиваем и я планирую на ее базе создать продукт на продажу. Далее я опишу основные принципы методологии учета, которые использую в этой разработке.
Зачем нужен учет:
1. Контроль обязательств в команде, внутренних и внешних. Если есть обязательство, то все заинтересованные в нем должны быть уверены, что оно либо будет выполнено, либо с ними будут согласованы корректировки. А в случае возникновения проблем с обязательством, о проблемах станет известно заранее, а не по факту его невыполнения.
2. Координация работы команды. Учет помогает обеспечить прозрачность работы для всех участников и понимание своей ответственности. А также стимулирует возможность и готовность запрашивать и давать уточнения когда что-то непрозрачно или расходятся представления о границах ответственности.
3. Уменьшение стресса. Большое количество разноплановых задач со сложной структурой связей, сроков и обязательств может вызывать стресс. Если эта структура становится более ясной и наглядной для всех участников, если появляется алгоритм приоритезации и фокусировки на задачах, а также если обеспечивается контроль обязательств и координация, тогда стресс уменьшается.
4. Чистое сознание. Если обязательства и детали по задачам находятся не в голове, а в системе, то остается больше мыслительных ресурсов на задачу, на которой человек сейчас сфокусирован.
Помимо учета для всего перечисленного необходима соответствующая корпоративная культура.
Структура учета:
1. Задачи распределяются по проектам.
2. Проекты могут быть привязаны к клиентам или направлениям деятельности.
3. Некоторые задачи могут быть не проектными, а операционными. В чем разница? Проект имеет цели, привязанные к срокам. Эти цели и сроки могут корректироваться в процессе. После их достижения проект завершается. А операционные задачи актуальны всегда. Например, развитие сотрудников - операционная задача. А создание нового программного продукта - это проект. После его завершения могут стать актуальными другие сопутствующие проекты (например, создание нового модуля для этого продукта) или операционные задачи (например, поддержка серверов, обеспечивающих функционирование этого продукта).
4. Задачи могут образовывать иерархию. Например, задача "развитие сотрудников" может быть разбита на подзадачи, они в свою очередь на другие подзадачи и так далее. В этих подзадачах конкретизируются направления развития сотрудников, действия для развития в этих направлениях.
5. Задача может иметь оценку трудоемкости.
6. К задаче могут быть привязаны фактические трудозатраты по ней.
7. К проектам помимо задач привязываются контрольные точки.
Учет операционных задач, как правило, проще чем учет проектных. Поэтому сосредоточусь на описании учета проектных задач.
Порядок подготовки к проекту:
1. Проект должен быть минимально возможным по размеру. Из пожеланий спонсоров проекта следует выделить минимальный объем пожеланий, дающий практическую ценность, MVP (minimum viable product) и отложить детализацию следующих частей до завершения MVP.
2. При планировании проекта важно определить набор задач, необходимых для реализации проекта. Это может сделать человек, у которого есть релевантный опыт, кто уже выполнял подобные проекты. В случае отсутствия такого человека, желательно его найти и привлечь к проекту.
3. Если привлечь такого человека затруднительно, то до согласования деталей проекта (в т.ч. сроков и бюджета) необходим этап исследования. Он подразумевает инвестирование определенных ресурсов на то чтобы попробовать выполнить часть задач и получить релевантный опыт для реализации проекта. В этом случае важно чтобы все заинтересованные в проекте лица понимали, что исследование может завершиться и без результатов, несмотря на затраченные ресурсы. В этом случае следует создавать дополнительные этапы исследования или отменить проект.
4. После определения набора задач необходимо оценить трудозатраты для каждой из них. Для этого также нужен человек с релевантным опытом. Он должен не только иметь опыт выполнения такого проекта, но и иметь опыт оценки и анализа трудозатрат по подобному проекту. При его отсутствии аналогично имеет смысл привлечь человека со стороны, либо организовать исследование, либо отказаться от проекта.
5. На основе полученных результатов можно оценить бюджет и сроки проекта.
6. Полученный набор задач с оценками трудозатрат и сроков вносится в систему учета, привязывается к проекту. Все эти задачи помечаются как входящие в проектную смету. На следующих этапах у них могут появляться подзадачи. Но всегда важно отличать задачи, которые были включены в смету на этапе согласования, от прочих задач.
7. Также закладывается резерв в рамках отдельной задачи проектной сметы. Это трудозатраты на непредвиденные обстоятельства и непредусмотренные задачи, которые могут всплыть в процессе. Для более-менее типовых и знакомых проектов я обычно закладываю резерв 20%. В других случаях увеличиваю.
Учет при реализации проекта:
1. Если конечный исполнитель той или иной задачи - это не тот человек, кто готовил задачи из проектной сметы, то он создает подзадачи в задачах проектной сметы. По ним он готовит свою оценку, которая может отличаться от оценки из сметы. Он это делает даже если у него не было релевантного опыта проектирования и оценки задач, это ему позволяет получить этот опыт.
2. Также конечные исполнители ежедневно или раз в несколько дней вносят фактические трудозатраты в проект и актуализируют статусы задач.
3. Менеджер проекта вносит в каждый из своих проектов ближайшую контрольную точку. Он должен обеспечить актуальную информацию о ближайшей контрольной точке проекта в любой момент времени. Контрольная точка содержит дату следующей контрольной точки. По ее достижению, менеджер создает новую контрольную точку. И так далее до завершения проекта.
Что описывает контрольная точка:
1. Состояние соответствия плановых и фактических трудозатрат.
2. Анализ причин расхождения плановых и фактических трудозатрат при их наличии и предложения улучшений на будущее.
3. Актуальный прогноз даты завершения проекта.
4. Прогноз фактических трудозатрат на дату завершения проекта.
5. Перечень рисков, их описание, предложения по работе с ними.
6. Рекомендуемую дату следующей контрольной точки. Иногда она может быть через пару дней, а иногда и через несколько месяцев (например, если решено заморозить проект до определенного срока).
Важный элемент корпоративной культуры - это право на ошибку. Не следует наказывать менеджеров или исполнителей за ошибки при планировании. Важнее анализ этих ошибок и рефлексия по их итогам. Плохим результатом является не разовая ошибка при планировании, а однотипная ошибка, которую один человек допускает раз за разом, не делая из нее выводов.
Ценность не в отсутствии ошибок, а в том чтобы они были частыми, быстрыми и дешевыми.
Контроль над проектом:
1. Менеджер проекта отслеживает и учитывает изменения по нему ежедневно или раз в несколько дней.
2. Раз в 1-2 недели проводятся собрания для ключевых заинтересованных лиц. На нем демонстрируются и обсуждаются текущие результаты, планируются корректировки.
3. Вышестоящие руководители, заинтересованные в успешной реализации пула проектов, но не участвующие в оперативных собраниях по ним, пользуются отчетом по актуальным контрольным точкам.
4. Собрание с менеджером для обсуждения статусов проектов с вышестоящим руководителем проводится индивидуально. Рекомендуемая периодичность - раз в месяц. Неэффективно обсуждать это на групповых собраниях сразу с несколькими менеджерами.
5. Тем не менее такие групповые собрания могут быть полезны, но не для обсуждения статусов. А для планирования загрузки, обсуждения новых проектов, кросскомандной координации по ним. Рекомендуемая периодичность подобных собраний - тоже раз в месяц.
Во многих командах распространена практика, когда руководитель слишком часто собирает своих подчиненных для получения информации о статусах задач. В ней есть два недостатка: неэффективное расходование времени подчиненных (они ждут своей очереди на собрании пока обсуждаются не актуальные для них вопросы), а также демотивация подчиненных (если есть проблемы в их направлении, то им неприятно говорить об этом на большую аудиторию, а тем более получать негативную обратную связь, в том числе из-за этого они начинают замалчивать проблемы). Более эффективно на таких собраниях обсуждать другие вопросы (но не статусы проектов). Информацию же о статусах собирать через автоматизированный отчет, а при необходимости обсуждения делать это индивидуально. То же самое относится не только к собраниям, но и к групповым чатам в мессенджерах.
Если вам интересно описанное, вы хотите что-то спросить, внедрить похожие процессы у себя в организации или получить консультацию, пишите мне на почту mp@mpros.ru или задавайте вопросы в комментариях.