Хотите всё успевать, но не знаете как этого добиться?

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

Вы перепробовали:

• календари;
• тайм менеджмент на грани садизма, когда поход в туалет тоже занесен как событие;
• L, XL, XXL подходы к взвешиванию задач;
• вставать раньше и ложиться позже;
• вообще не ложиться - сон - это для слабаков;
• кофеин и прочий микродозинг

Это всё не помогает. Помогает понимание того, что для вас важно в каждый конкретный момент времени и почему.

Сроки в разработке

Один из KPI, который выдвигается для Prodact-ов, - это своевременность поставки функциональности и/или продукта. Например, ваша команда создает функциональность "видео-отзывы" для маркетплейса, и эта возможность должна быть доступна для пользователей маркета в определенный момент. Потому что есть конкуренты, потому что есть внешние договоренности, есть инвесторы, в конце концов, есть потребители.

Само по себе наличие дедлайна - уже стрессовый момент. Я считаю большой ошибкой, когда срок поставки задается конкретной датой, например, 3-го сентября. Более эффективная альтернатива "красной дате" - это временной промежуток. Например, "в спринте N", "в третьем квартале" и так далее. Это добавляет воздуха и значительно снижает уровень тревожности не только для части команды, которая занята непосредственно разработкой, но и для маркетологов, специалистов поддержки, словом, всем на всех уровнях становится проще и легче без потери в понимании сроков поставки.

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

• изменения требований;
• высокая степень абстракции при проектировании;
• низкая отказоустойчивость продукта;
• низкая эффективность коммуникаций

Попробуем разобраться

Изменения требований

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

Абстракция при проектировании

Если же команда работает над требованиями, инвестирует в проектирование продукта или функции продукта, но всё равно выкатывается за оговоренные ожидаемые сроки поставки. Но почему теперь-то?

Разработка продукта - это всегда создание нового в условиях существенной неизвестности. Не скажу, что это как светить фонариком в черную дыру, но где-то рядом.
Проектирование продукта или функции продукта - это практически его написание, только на бумаге. Это крайне кропотливый и дорогостоящий процесс, который не гарантирует 100% корректности, тем не менее значительно уменьшает вероятность упереться в "блокер" и создание обходящего его "костыля".

Достаточную степень проработки на уровне проектирования можно только наработать, её нельзя рекомендовать или назначить.
Себестоимость же проектирования напрямую зависит от того, насколько описан продукт и его отдельные компоненты.
То, что не любят делать почти все разработчики - это описывать собственный код. Следствие этой нелюбви - возрастающая себестоимость развития продукта, высокий уровень абстракции при проектировании.

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

А что бывает, когда принятие решения спущено на уровень разработчика? Правильно - карусель из доработок и переноса сроков.

Отказоустойчивость

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

• нет культуры работы с требованиями;
• проектируют с уровнем абстракции Пикассо;
• отсутствует балансировка фич на уровне спринта и деплоя;
• нет рефакторинга

Коммуникации

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

Как же это лечить?
Только не ежедневными meetup-ами и "синками"! Я считаю их злом и вот почему.
Во-первых, meetup - это не про общение, это про что-то другое.
Во-вторых, время, которое член команды проведет на встрече, будет полностью потрачено на встречу, независимо от того, насколько целевой она была для каждого.

Лечение - это нахождение и постановка нужных членов команды на нужные коммуникационные узлы. За счет этого потеря информации будет минимальной.
Что я имею в виду?

• Если на базовом узле коммуникаций находится член команды, который говорит только на языке бизнеса - вы получаете мискоммуникацию.
• Если на базовом узле коммуникаций находится член команды, который говорит только на языке разработки - вы получаете мискоммуникацию.
• Если член команды не говорит и не понимает ни одного из языков - что он делает в вашей команде?

Про Всё и Успеть

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

Я хотела Всё Успеть.

Это аффективное расстройство в моем случае длилось достаточно долго - годы. Пока не уперлось в эмоциональное и физическое выгорание, граничащее с депрессивным расстройством.

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

Подумайте над тем, что для вас действительно важно. Разрешите себе быть подвижным. Ведь окружающий вас мир меняется каждый момент времени. Отпустите ситуацию хотя бы чуть-чуть, вы не потеряете в управляемости, но напряжение, которое вы испытываете, будет менее болезненным.