{"id":6545,"title":"\u041a\u0430\u043a \u0438 \u0437\u0430\u0447\u0435\u043c \u043a\u0440\u0443\u043f\u043d\u044b\u0435 \u0431\u0440\u0435\u043d\u0434\u044b \u0441\u043d\u0438\u043c\u0430\u044e\u0442 \u0440\u043e\u043b\u0438\u043a\u0438 \u0434\u043b\u044f TikTok","url":"\/redirect?component=advertising&id=6545&url=https:\/\/vc.ru\/tiktok\/293387-brands-in-trends&placeBit=1&hash=07ebf9a0a17c2f85811d24fb804e09e72513fa4c7cc999d1730b233d3c9348bd","isPaidAndBannersEnabled":false}
Карьера
Dmitry Kotenko

Всегда горят сроки: что мешает работать по плану

Ни один IT-проект не обходится без увеличения сроков и бюджета, если в него добавляются все новые и новые функции. Придерживаться плана выходит далеко не всегда, и это не обязательно плохо. Рассказываем, что помогает нам в InfoShell не терять голову на проектах и держать их в рамках.

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

I. Налаживаем коммуникацию с заказчиком

Помимо очевидного разговора о функционале и миссии проекта это принесет ощутимую пользу в предотвращении конфликтов. В общении с заказчиком есть 2 крайности:


ПЕРВАЯ

Заказчик не вовлечен в разработку.
Она уже идет полным ходом, все фичи согласованы, прототипы заходят «на ура», и мы уже готовы встречать довольного клиента, как вдруг выясняется, что это все не то. Нужно все переделать, все заново обговорить, имелось в виду совсем не то, что получилось. Занавес.
Помимо переработок, раздутого бюджета и конфликтов, мы получаем демотивированных сотрудников, с которыми нам предстоит переделывать проект.

ВТОРАЯ
Заказчик контролирует каждый шаг команды.
В этом случае все члены команды вместо работы над продуктом усиленно работают над отчетностью, уделяют рабочие часы созвонам. Чаще всего это проблема не налаженной коммуникации. Заказчик сомневается в вашей профессиональной компетентности? Сомневается в том, что вы правильно его поняли? Предупреждайте такие мнения ДО начала проекта. Позднее, поверьте, не получится.

Итак, до начала разработки обязательно:

а) обговариваем видение проекта;
б) предлагаем свои варианты решения;
в) детально(насколько это возможно) обговариваем функционал;
г) обговариваем сроки и возможные риски;
д) рассказываем, как лучше всего строить коммуникацию и отчетность. И корректируем по усмотрению заказчика.

Фундамент заложен, но расслабляться нельзя – ещё больше возможностей провалить сроки ждет нас во время проекта. Если команда работает по Scrum, она может менять функционал продукта прямо по ходу разработки, если продукт от этого изменения станет лучше или этого требует заказчик. Это здорово, но влечет за собой ряд неприятностей. Например, трудно контролировать расширение объема задач. Поэтому каждый спринт мы перераспределяем задачи и корректируем процесс. Но это не работает, если мы не можем оценить загруженность и эффективность каждого члена команды.

II. Делаем процесс прозрачным

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

а) какие задачи предстоит выполнить?
б) на каком этапе разработки находится конкретная задача?
в) кто занимается выполнением этой задачи?
г) сколько времени потрачено на выполнение задачи?

Нам с этим помогает доска спринта.

Доска — основной показатель продвижения проектного процесса и прекрасно работает, когда нужно отследить:

a) личную эффективность разработчика/менеджера/тестировщика;
б) загруженность члена команды, чтобы при необходимости перестроить процесс.

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

III. Налаживаем коммуникацию с командой и проактивность

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

Сотрудники обсуждают X и считают, что обо всем договорились (нет) => X пускается в работу => X наполовину готов => закрадывается подозрение, что что-то пошло не так => сотрудник тратит ещё некоторое время на то, чтобы убедиться, что что-то пошло не так => обращается к сотруднику из начала цепочки => сотрудники обсуждают X и считают, что обо всем договорились. Хорошо, если на этом этапе X наконец пойдет в разработку. Плохо, если цепочка станет циклом. Такие ситуации не происходят часто, но единичные случаи сильно бьют по разработке и их достаточно.

Поэтому нетрудно вывести общие правила для всех, кто разрабатывает IT-продукт:

а) будьте ответственны за то, что вы делаете. Осмысляйте свою работу.
б) понимайте, почему эта фича важна в проекте. Как можно её улучшить? В чем она плоха?
в) если что-то в проекте непонятно, вызывает вопросы, требует улучшения — это должно быть озвучено.
г) если вам есть, что предложить — делайте это. Не думайте, что проактивность в разработке тормозит проект. Что его тормозит наверняка, так это незаинтересованная команда.

IV. Закладываем риски

Кто-то ушел в отпуск, работа backend тормозит работу разработчиков, идет борьба со сторонними сервисами. Не планируйте жизнь в вакууме, посмотрите на проект сверху и задайтесь вопросом: «Где могут возникнуть проблемы?». Уделите больше внимания тем частям проекта, в которых все зависит не только от вашей команды.

V. Используем метрики

Например:

Burn up chart – диаграмма, которая наглядно показывает, сколько осталось сделать до конца спринта. И если изменяем скоуп задач, конец проекта на графике сдвигается. С помощью burn up мы прогнозируем, ставим гипотезы, выбираем лучший путь.

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

Velocity – показывает, как быстро мы «съедаем» объем задач и какой объем работ осталось выполнить. Вычисляется как КПД. Нужно выбрать метрику трудозатрат (рабочие часы на проекте/задачи и т.д.) и разделить количество эффективных часов на проекте на количество рабочих часов. Подробный пример разобран в статье «Налаживаем процессы в продуктовой команде». Наглядность происходящего делает его регулируемым. Мы не ориентируемся на среднюю прогнозируемую эффективность, а регулируем эффективность относительно проекта.

VI. Рефлексируем

В конце проекта проведите встречу, чтобы обсудить не конечный продукт, а работу команды над продуктом. Суть в том, чтобы подтолкнуть всех членов команды (в том числе и себя самого) к анализу собственной работы, на который у нас никогда не хватает времени. Пусть каждый из членов команды ответит на 4 вопроса:

1) Как я участвовал в проекте? Не какие были у меня обязанности, а что я сделал по факту.
2) Какие у меня возникали проблемы?
3) С чем у меня были трудности? Удалось с ними справиться или нет?
4) Что бы я улучшил в своей работе?

Рефлексия в первую очередь должна проводиться для каждого участника команды, а не для техлида или менеджера. На ней не должно быть никакого осуждения и привычного «разбора полетов». Не пренебрегайте рефлексией.
Итак, краткое summary о том, как держать проект в рамках:

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

Мы разрешаем отодвинуть сроки:

а) когда это происходит из-за требований заказчика по расширению функционала;
б) когда это сделает проект лучше;

Если ни одна из вышеприведенных мер не решает ваших проблем (убедитесь наверняка), тогда…

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

Напоследок

Не нужно бояться факта изменения проекта. Не бейтесь головой о стену из-за того, что что-то идет не по плану. Тратьте время на прогнозирование и поиск лучшего подхода. Опережайте проблемы, предлагайте пути развития проекта, а не ждите, пока проект сам сообщит вам, что нужно что-то менять. Воспринимайте изменения в плане как возможность, а сдвиг дедлайна — как необходимую меру. Удачи в работе!

{ "author_name": "Dmitry Kotenko", "author_type": "self", "tags": [], "comments": 7, "likes": 8, "favorites": 34, "is_advertisement": false, "subsite_label": "hr", "id": 61644, "is_wide": true, "is_ugc": true, "date": "Tue, 19 Mar 2019 14:24:10 +0300", "is_special": false }
0
7 комментариев
Популярные
По порядку
Написать комментарий...

А если члены команды не захотят ответить на 4 вопроса?

2

а) будьте ответственны за то, что вы делаете. Осмысляйте свою работу.

кмк написано плохо. "Осмысление" может быть достаточно субъективным мероприятием. Намного важнее синхронизация участников:
1 - Заказчик и исполнитель должны понимать, что будет в конце проекта и на ключевых его этапах.
2 - Участники команды должны четко понимать, что каждый из них должен сделать, каким образом (если это релевантно - часто это важно при работе front- и back-end специалистов) и что должно быть получено в конце итерации (спринта, этапа работ)

2

Разумеется. Про понимание говорилось в том числе в пункте II и III.

0

Но, в принципе, вы правильно указали на неточность. Возможно, стоило бы все сосредоточить в одном пункте. Спасибо за комментарий)

0

Очевидно, это затруднит рефлексию. Остается сверять количество часов, тасков по факту. И уже с этим идти к команде за комментариями. Возможно, стоит проводить такие мероприятия индивидуально с каждым, если команда была не очень большая.

1

А разве рефлексия входит в должностные обязанности ?! Или можно пургу нести в рабочее/оплачиваемое время ?

0

Обсуждение того, насколько качественно была проведена работа и какие ошибки (если они были) сделаны, – такой же рабочий процесс, как составление бэклога, разработка или коммуникация с заказчиком, на мой взгляд.

0
Читать все 7 комментариев
Слабое звено бизнеса — уверенность. Разбираемся, как ее достичь

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

Evrone News #08: выступили на конференциях и провели первый Evrone Fest

В этот раз наша традиционная подборка посвящена мероприятиям. Во-первых, наши спикеры отлично выступили на PyCon и RnDTechConf, а во-вторых, мы провели свой первый Evrone Fest. Подробности ниже.

Премьера второго сезона сериала «Молодые и сильные. Проклятие выживших»
Пивозавро-стикеры для IT

Мы вдохновились мемом про пивозавра и сделали про него айтишные стикеры

Как IT-компания делает продукты: история собственной торговой марки Яндекс.Лавки
Популярный ресурс indiehackers.com заблокирован РКН

Уже почти целый месяц популярный среди независимых разработчиков по всему миру ресурс www.indiehackers.com заблокирован РКН по решению Кудымкарского городского суда Пермского края.

Amazon впервые с 2018 года обновит Kindle: в новой версии — увеличенный экран и режим автономной работы до 10 недель Статьи редакции

Стоит от $140.

Kindle Paperwhite Amazon
«Яндекс.Такси» начнёт страховать своих водителей и курьеров за 800-2000 рублей в день Статьи редакции

Всего на программу страхования курьеров и водителей компания выделит 1 млрд рублей.

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

Всем привет!

Суть проблемы: хотел было перелогинится в Яндекс.Диске на десктопе, а он попросил меня ввести ответ на контрольный вопрос, который за давностью лет я забыл, т.к. ящик заводился в далеких нулевых. В 25-27 лет и на заре российского интернета казалось, что ответом на вопрос "Любимое блюдо" обязательно должно быть что-то оригинальное…

Figma mockup Plugin от ls.Graphics

ls.Graphics выпустила обновленный и бесплатный Figma плагин для работы с мокапами. Кроме этого, в нем уже есть новейшие мокапы iPhone 13. 🤘🏻

null