Оценка задач

Привет. Давайте я расскажу вам о своем опыте в оценке программных продуктов. Я занимаюсь этим без перерывов уже 15 лет, и мне бы хотелось поделиться опытом и эволюцией моих взглядов на оценку. Уверен, что это будет полезно. Начнем с целеполагания. Зачем вообще оценивать? Кому это надо?

Ответ на самом деле очень простой людям хочется определенности, в частности ответа на вопрос когда будет готово?. Когда мне можно в отпуск, когда начнутся продажи, когда делать связанную задачу. С другой стороны мало ли что люди хотят, почему из-за чужих желаний тратить свое время на это занятие?

Но, в конечном счете, нам всем бы хотелось получать зарплату, а зарплата не из воздуха появляется, ее компания берет из выручки, в отдельном случае из инвестиций. А чтобы эта самая выручка была, нам надо достигать бизнес-цели. А люди, которые формулируют бизнес-цели очень любят всякие финансовые формулы ROI, LTV и прочая EBITDA. А в этих формулах постоянно фигурируют сроки. Без них крокодил не ловится, не растет кокос.

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

Как следствие: скорее всего, оценивать все же придется. Смиритесь.

А теперь поговорим о том, как это сделать, чтобы не проклясть все и всех в процессе. Как обычно оценивают люди, которые не умеют оценивать ИТ-шные штуки? Вот так:

• Оцениваем всю работу в человекоднях.
• Добавляем 10% на всякий случай.
• Делим на количество разработчиков.
• Прибавляем получившееся количество дней к текущей дате и получаем итоговую дату.
• Вот и все.

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

Ты не выделывайся со своими сторипоинтами, ты рукой покажи.

С какими проблемами предстоит столкнуться во время оценки

Начнем с идеальной ситуации:

• У нас есть атомарная (простая, неделимая) задача.
• У нее нет зависимостей от других задач, не надо ничего согласовывать.
• На задачу есть на 100% выделенный человек, который знает, как ее делать.

Даже в таком случае встает вопрос Кто будет делать оценку?. В этот момент запускается неумолимая машина управления. Сначала менеджер думает: если это будет делать разработчик что ему помешает указать огромные трудозатраты чтобы повалять дурака? -> Поэтому менеджер оценивает задачу сам. -> Однако менеджер недостаточно глубоко разбирается в теме и не видит (или не хочет видеть) подводные камни. -> Оценка оказывается непоправимо заниженной. -> Команда не укладывается в срок. -> Смерть и тлен.



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

Культура недоверия очень часто встречается в связке с корпоративной культурой страха: даже если задачу оценивает разработчик, то что происходит у него в голове во время оценки? Он отвечает на вопрос: А как в моей компании реагируют на несоответствие планируемых сроков и фактических?. Если за проваленные сроки задач разработчика ругают он будет их завышать. Если за сделанные раньше срока задачи дальнейшие оценки разработчика будут срезать, то он не будет сдавать задачи заранее.

Новейший пример культуры страха релиз игры Cyberpunk 2077. Игра вышла в отвратительном качестве на консолях прошлого поколения. СЕО компании в своем заявлении сказал, что как оказалось, во время тестирования не были обнаружены многие проблемы, с которыми вы столкнулись в игре. Что, разумеется, тотальная ложь. Проблемы были видны невооруженным глазом, тестеры физически не могли такое пропустить. Это типичная ситуация для культуры страха: проблемы замалчиваются. Так информация по пути до верхнего этажа менеджмента превратилась из игра неиграбельна на базовых консолях в давайте релизить.

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

И вот вы дали оценку, например 1 неделя. Это всего лишь ваше предположение, не более. Оценка определяет запланированный срок завершения задачи, но не может определять время ее фактического завершения. Где конкретно будет фактическое время завершения задачи описывается нормальным распределением. Пока просто запомним это как аксиому, в конце будет сюжетный поворот.



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

А еще мы не умеем видеть будущее. Как следствие постоянно возникают задачи, которые мы не предусмотрели, да и не могли предусмотреть. Что это может быть?

• Хотелки клиентов или Product Ownera.
• Внезапные проблемы, под которые надо что-то доработать.
• Неожиданный legal.
• И тонны всего прочего.

Самое непредсказуемое проблема разной скорости разработчиков.

У реальных разработчиков одного уровня и с одной зарплатой производительность может отличаться на порядок:

• Кто-то неделю будет пилить и отлаживать код, а кто-то за полдня прикрутит открытую библиотеку.
• Кто-то будет курить Stack overflow, а кто-то уже решал такие задачи и сходу начнет приносить пользу.

В итоге наша гауссиана превращается во что-то такое (так же выглядит оценка, когда задача недостаточно отгрумлена):



В общем, все сложно, мы тут не траншеи роем. Как же сделать хорошую оценку в таких условиях?

Критерии хорошей оценки:

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

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

• Набираем задачи в бэклог продукта.
• Оцениваем самые высокоприоритетные стори в бэклоге любым методом (методов много, про них ниже расскажу).
• Начинаем работать (например, по скраму спринтами).
• После нескольких спринтов меряем сколько стори поинтов у нас получается в среднем каждую итерацию. Это наша Velocity усредненная скорость разработки команды.
• Оцениваем весь бэклог. Теперь у нас появляется достаточно информации чтобы можно было нарисовать burndown chart. Точка пересечения с осью абсцисс в идеальном мире показала бы, когда мы закончим.

Но мир не идеален, поэтому фиксируем, сколько новых фич (тоже оцененных в сторипоинтах) генерит наш Product Owner каждый спринт. Красная линия покажет разрастание бэклога, теперь пересечение красной и синей линии нужная дата.



Если Product Owner очень креативый, то может быть даже так:



А теперь вспоминаем, что оценка подчиняется законам нормального распределения, а вот и сюжетный поворот такие гауссианы отлично складываются. Поэтому получается вот что (это называется enchanced burndown chart):



Казалось бы, сбылась мечта юного математика: из кучи хаоса мы получили красивый график и можем с умным видом вещать что с 50% вероятностью мы закончим в 14 спринте, с 80% вероятностью в 17-м, с 95% в 19-м.

Во всем этом процессе есть ряд подводных камней.

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

Во-вторых, проблема разработчики работают с разной продуктивностью никак не решается в принципе. А значит, у нас получается очень пологое нарастание вероятности, которое мало помогает принимать управленческие решения: с 50% вероятностью мы закончим в 14 спринте, с 80% вероятностью в 27-м, с 95% в 39-м так на языке математики звучит пальцем в небо.

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

Метод Покер планирования

Это одна из самых популярных техник оценки, наверное, потому что самая старая.

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

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

Метод выстраивания порядка

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

• Когда наступает время оценки, каждый участник команды по очереди совершает свой ход (как в настолке). Ходы могут быть такими: поставить таск на шкалу, передвинуть таск по шкале, обсудить историю с коллегами, пропустить свой ход.
• В результате, задачи постоянно перемещаются по доске, их оценка друг относительно друга уточняется, пока не получится состояние, удовлетворяющее всю команду.
• Когда все участники пропускают свой ход готово.

Это быстрая техника. С ее помощью можно оценить 15-20 историй в час, чего обычно вполне достаточно.

Метод Большой/маленький/непонятный

Пользовался несколько раз, но не прижилось.

• На доске отмечаются 3 зоны: большой таск, малый таск и недостаточно информации.
• Команда проводит групповое обсуждение нескольких первых задач, определяясь с терминами большой/маленький. Я настаиваю на толковании термина маленькая задача = может сделать один человек в спринт.
• После этого все юзерстори индивидуально вешаются на доску в нужные зоны.

У метода огромный плюс он супербыстрый. Так можно обработать по 50 пользовательских историй в час.

Тут возникает проблема с трансляцией этих оценок в стори поинты, но когда уже известна velocity команды, то мы понимаем сколько сторипоинтов пережует человек за спринт и в Jira и оцениваем маленькие задачи вокруг этой метрики.

Что касается остальных задач. Я отправлял таски из области недостаточно информации в аналитику, а задачи из большой таск на декомпозицию, чтобы на следующей сессии оценить их заново.

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

---

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

Привет, Хабр! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.

Это происходит не потому, что мы фейлим задачи, а потому что c традиционным Estimate в реальности мы оцениваем лишь время написания кода разработчиком. А ведь есть еще тестирование и код-ревью. Ок, заложим это всё в оценку. Но ведь ещё:

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

Как научиться отвечать на вопрос Когда?, если о предсказуемости речи не идёт?

Как мы усомнились в Estimate

В нашей команде, как и у многих в компании, есть очень полезная встреча техническое ревью (или, сокращенно, техревью). Она требует приличного количества времени и сил, зато добавляет предсказуемости: мы заранее расписываем техническое решение задачи, а заодно оцениваем ее.

Так как мы всегда на удаленке, всё происходит в JIRA: есть доска, на которой визуализированы этапы работ. Карточка покидает статус Техревью и перебирается в Готово к разработке после того, как мы все описали и оценили. Именно в этот момент мы берем на себя обязательства выполнить работу.


У Готово к разработке стоит WIP-лимит больше 8 задач одновременно быть не может. Есть и обратное правило: как только задач в колонке становится мало, мы инициируем новое техническое ревью.

Факт: мы тратим заметное время на оценку. Техревью обычно проходит два раза в неделю, на 4 задачи с детальной проработкой и оценкой может уйти 1,5-3 часа. Но! Затем мы еще можем потратить время, чтобы разобраться, почему Estimate таки был превышен.

При этом ни оценка, ни разбор полетов не добавляют ценности нашему продукту. Скорее, на них мы теряем время. И деньги. Я долго сомневался в необходимости этих процедур, а в один момент дозрел до серьезного разговора с продактом. И мы оба признали проблему.

Футболка сухая и совсем... не XS

Решили: давайте экспериментировать с подходами к оценке. Я предложил остановился на T-Shirt Size в качестве единицы измерения в этой технике используются размеры футболок. Нужно найти самую маленькую задачу, которую приходилось делать, и принять ее за XS. После этого остальные задачи оцениваются по принципу насколько они больше XS и в зависимости от этого им присваивается размер S, M, L или XL.


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

Погрешность в день-два заказчик нам простит значит, никаких больше разборов полетов. А на техревью не надо будет тратить время на интерактивы и тайные голосования. Все гладко!

Работаем так несколько месяцев, собираем статистику. И только Иван на нас косо смотрит.

Выяснилось, что XS, как и S, мы делаем то за 1 день, то за 10. А на L тратим то 5, а то 15 дней. Потому что по факту какую-то работу мы берем в первую очередь, какую-то во вторую, а какую-то в пятую и задачи одинаковой размерности проводят в статусах ожидания разное время. Упс, вот тебе и средние.

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

Все любят тортики. Слоёные! Осел из Шрека

И я люблю. К тому же, день рождения ребенка это отличный повод! Захожу на свой любимый сайтик и начинаю выбирать:

• можно такой, а можно и не такой,
• можно украсить, а можно не украшать,
• можно на 2кг, а можно и на 5кг.

Не буду раскрывать свои вкусовые предпочтения, а тортик я выбрал. И привезли его к назначенной дате. Далее пойдет философия объевшегося торта тимлида.

Я, разумеется, не Ньютон, а тортик не яблоко, но озарение пришло.

Я мог выбрать из множества вариантов, но что бы я ни выбрал, дата доставки не менялась. Мне нужен был торт через неделю. И мне были готовы оказать эту услугу. А размер торта, вес и всякие прибамбасы не сильно влияли на конечный результат точнее, в данном случае, вообще не влияли. Дело не в размере, как говорится. А в чем? В цене.

Например, у ребят был экспресс-заказ: за дополнительную плату мне привезли бы тот же навороченный торт всего через пару дней, а не через 5. Мой заказ, как наиболее ценный по сравнению с другими, пошел бы вне очереди. По сути, у кондитерской есть два SLA: для обычного заказа и для VIP. Тут есть над чем подумать.

Идея с SLA триггернула, потому что я читал про это в Канбан-гайде

С точки зрения Канбан-метода всё есть сервис. И несмотря на то, что мы поставляем не тортики, а наш продукт нельзя пощупать или съесть разработка тоже сервис. И мы также по-разному относимся к задачам.

Вспомним нашу доску:


Сервис состоит из нескольких этапов (разработка, код-ревью, тестирование), а колонка Готово к разработке это наша точка коммита перед заказчиком.

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

Как оценить SLA своей команды: строим спектральную диаграмму (это просто)

Чтобы разобраться с тем, какие классы обслуживания у нас есть и какие у них SLA, Канбан предлагает построить следующий график:

• По оси Х фиксируем Lead Time (LT) время производства задачи. В нашем случае это время от Готово к разработке до Готово.
• По оси Y откладывается частота сколько задач мы сделали за LT1, LT2, LT3 и т.д.

Мы взяли закрытые за последние несколько месяцев задачи и получили следующее:


Мы закрыли 3 задачи за день, 6 за два, больше всего за 5, а где-то бились над таской больше двух недель

Ну а теперь время анализировать. Что это за задачи? Почему они попали именно сюда? Почему мы делаем в определенный LT больше, чем в другие, что там? Копать можно вплоть до заказчиков и исполнителей, а также изучать комментарии к таске.

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


Разброс довольно большой, но он поддается анализу.

В целом, основная масса задач распределилась в промежутке 7-14 дней, а парочка улетела совсем далеко в этом хвосте было несколько задач (не все) с PR в другие сервисы. Те задачи, что завершились за 3-4 дня, скорее исключение, чем правило.

Итак, я уже могу сказать заказчику, что если задача проходит как регулярная работа, с вероятностью 75% она доедет до прода за 10 дней.

А с вероятностью 90% это займет 14 дней. Ну а если разработка затрагивает другие сервисы компании, ждать придется немного дольше, нам нужен код-ревью от другой команды и потом еще деплой.

Поехали дальше. Мы назвали этот класс Важный.


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

И тут мы также можем озвучить SLA: с 75% вероятностью задача попадет на прод за 5 дней, с 90% вероятностью за 7. Продолжим?

Те самые задачи, ради которых мы бросаем всё и пилим, пилим, пилим блокеры.


В 100% случаев это мелкие доработки, которые мы не учли при реализации основной фичи, либо баги, которые аффектят жизненно важный функционал на проде.

Несмотря на то, что все подобные ситуации нам удалось разрешить за 2 дня, всё равно озвучим 90ый процентиль. Во-первых, не стоит обещать 100% никому и никогда :) Во-вторых, нужно закладывать вариабельность: вспомним случай с регулярной работой, когда несколько задач улетело за 20+ дней, потому что появилась зависимость от других команд.

Готово! Можем согласовать с Ваней SLA по всем классам обслуживания:


Мы выбрали именно 90% по срокам это, по сути, толерантность заказчика к их несоблюдению. То есть, если 1 из 10 задач не уложится в SLA, нам готовы это простить.

Если ваш заказчик не такой добрый, лучше озвучивать 95ый процентиль, например.

Вместо заключения

А что мешает Ване набирать только важные задачи или блокеры?
Горизонтальные WIP-лимиты.

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

Спасибо за внимание и успешного вам планирования!

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

Топ 10 советов

• Не обращай внимание на существующую кодовую базу, такой профессионал как ты всегда сможет решить задачу в любой кодовой базе. Ведь ты, дружище, добавлял новый экран в свой пет проект за пару часов? И я добавлял, так что на боевом проекте все будет также.
• 
• Ни в коем случае не советуйся с коллегами перед оценкой. Что они могут знать о твоей задаче, им бы только пообсуждать, как бинарное дерево ревертнуть. Ты лучше знаешь как нашлепать формочек для нового экрана и сколько времени это займет.
• Запомни: никакого дополнительного времени на прохождение код ревью. Твой великий код должен всем понравиться с первого раза. Иначе ведь и быть не может.
• Поддавайся уговорам снизить эстимейт, надо ведь всегда быть дружелюбным, чтобы все вокруг были довольны твоей оценкой. Даже если просят вместо 40 часов сделать за 8 все равно соглашайся, авось прокатит. Зато менеджер доволен.
• Всегда исходи из того, что будешь писать грязный код зато быстро, ну а что потом разберешься со сложностями поддержки плохого кода, зато менеджер доволен твоим перформансом и оценками.
• Никогда не слушай коллег с других платформ, что эти айосники могут знать о твоем великом андроиде. Или что эти выскочки с мобилок, которые умеют только формы шлепать, могут знать про тонны логики на твоем великолепном бэкенде? Их слушать незачем.
• Запомни: крутые парни или девочки не переспрашивают, если тебе непонятно и половины того, что от тебя хотят, просто тыкни пальцем в небо и дай оценку, а там уже разберешься. Зачем тратить свое драгоценное время на какие-то разговоры и выяснения, ты поэт, твое дело творить !
• Не думай об интеграции. Разве на то, чтобы провести интеграцию мобилок с бэкендом нужно время? Да не, бред какой-то.
• На ручное тестирование совсем не уходит время. Да и твой великолепный код не нужно тестировать ручками, он должен великолепно работать без крашей и проблем.
• Будь смелым, никогда не делай оценку с запасом, ведь всегда есть возможность и на выходных поработать, а выгорают только слабаки. Такому крутому перцу как ты это не грозит.

А теперь к полезным советам

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

• Всегда следует давать оценку, исходя из существующей кодовой базы.
  Исключение составляют те случаи когда проект начинается с нуля, но даже в таком варианте следует учитывать, что уйдет время на продумывание архитектуры и путей взаимодействия сущностей в системе. Будет здорово если ты перед каждой оценкой задачи будешь открывать код и смотреть, что будет модифицироваться и какие проблемы возможны.
• Если в оценке есть сомнения то лучше посоветоваться с коллегами перед тем как выносить вердикт. Это хорошая практика даже если у тебя нет ни капли сомнения в своем эстимейте. На случай если советоваться не с кем, то будет круто даже если ты поищешь совета в сообществе, учитывая NDA своего проекта. Мнение со стороны может пролить свет на какие-то нюансы, которые ты сам не видишь.
• В свой эстимейт всегда нужно закладывать время, которое уйдет на прохождение код ревью. Это касается проектов, на которых есть практика проверки кода коллег. Количество времени, которое стоит заложить сильно зависит от проекта и от того будешь ты дробить свои пул реквесты на небольшие или выливать все сразу скопом. Зачастую на прохождение ревью может уйти больше времени, чем ушло на написание самой фичи. Старайся дробить свои пул реквесты на более мелкие.
• НИКОГДА НЕ поддавайся уговорам снизить эстимейт, у тебя есть уверенность в своей оценке, а она будет, если ты следуешь шагам, описанным выше. Менеджеры всегда хотят задачу побыстрее и подешевле, но это не коррелирует с реальным миром. Если ты поддашься, снизишь оценку, а потом не попадешь в нее, то виноват будешь только ты.
• Ты как ответственный специалист должен думать о том, что писать чистый код иногда медленнее чем грязный, а следовательно стоит об этом задумываться при эстимейте.
• Бывает полезно прислушаться к мнению коллег с соседних платформ. Конечно у каждой платформы своя специфика. IOS определенно отличается от Android, но зачастую ваша система имеет одинаковую бизнес логику и тут и там и шаринг мнений помогает увидеть дыры в этой логике и что может пойти не так.
• Если у тебя есть вопросы или что-то не понятно всегда переспрашивай. В требованиях могут быть шерховатости, что-то невозможно реализовать в принципе на твоей платформе. Где-то есть добавление, которое ломает всю логику системы Не ленись тратить время на то, чтобы прояснить все вопросы, это избавит тебя от большой боли в жопе голове.
• Всегда думай о том, что на интеграцию с серваком или мобилками уходит время и возможно придется, что-то менять. Этот пункт не самый значительный из всех, но все же стоит задумываться и об этом.
• На ручное тестирование УХОДИТ время. Необходимо держать в уме возможные баги, и время, которое будет потрачено на них. К сожалению, ошибки и баги всегда идут рука об руку с каждой новой написанной строчкой кода.
• Есть поговорка: запас оценку бережет. Всегда следует думать о рисках, которые мы никак не предусмотрим, например:
  
  
  1. Сразу после обновления ПО у тебя не получается начать работу
  2. Сделал обновление среды разработки и перестал компилироваться проект
  3. Метеорит упал на офис
  
  
  Именно для этого следует подстелить себе немного соломки на случай если придется падать.
  Как-то я ошибся с оценкой ровно в 10 раз и вынес из этого несколько уроков, надеюсь для кого-то кроме меня это тоже будет полезно.