Почему важно правильно описывать задачи на разработку?

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

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

#agile_который_работает #владельцу_продукта

https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

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

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

#тимлиду

https://www.youtube.com/watch?v=KrTKSDGMDk8

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

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

Получить консультацию можно любым удобным способом:
⁃ через наш сайт
⁃ почту: info@itleadassist.io
⁃ написать нашему администратору @shalamova_as

Сегодня мы подготовили для вас подарок! 🎁
Бесплатный чеклист на ввод нового сотрудника в компанию. Он пригодится не только руководителям любого уровня, но и всем кто менторит новичков. А если вы сами устраиваетесь на новую работу, то будет полезен в качества первоначального плана на испытательный срок, подскажет что узнать у своего руководителя и коллег для отличного старта на новом месте.

Делитесь с друзьями, давайте вместе сделаем адаптацию новых сотрудником комфортной и эффективной!

#чеклист

Действенный способ измерения эффективности на удаленной работе
Многие при переходе на удаленную работу столкнулись с проблемой измерения эффективности команды. Хотите узнать способ, который реально работает? Мы все разобрали в своей статье. Спойлер: измерение времени не поможет 😕

#тимлиду #владельцу_продукта

https://oros-it.ru/blog/efficiency-metrics?utm_source=tg&utm_medium=article&utm_campaign=time

Долгожданная статья-инструкция от Максима Шаламова "Как стать тимлидом"! С этой информацией у вас точно получится добится любой желаемой должности. Не теряйте ни минуты, забирайте, пока ваши конкуретны ее не нашли 🤫

#тимлиду

https://oros-it.ru/blog/how-to-become-a-teamlead?utm_source=tg&utm_medium=article&utm_campaign=howtoteamlead

Мы долго думали говорить ли вам и все же.... мы готовим исключительный материал специально для тех, кто хочет расти по карьерной лестнице. Но пока это секрет 🤫

А пока вся наша команда усердно работает, мне удалось утащить для вас кусочек этой невероятной полезности и оформить в очередной подарок 🎁. Забирайте чеклист "Вывод сотрудника из выгорания" совершенно бесплатно! (качайте скорее пока мы не передумали 🙊)

#чеклист

Рубрика “Разбор кейсов”
Чувствительный руководитель

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

Разбор:
Эта ситуация одна из самых деликатных. Но не стоит ее игнорировать. Вам нужно продолжать работать, а такое поведение руководителя может подвести вас и ваших коллег. Однако, работать со слабостями руководителя нужно очень осторожно, чтобы не усугубить ситуацию, а заодним и себе жизнь.

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

1. Сохраняйте спокойствие. Успокоить другого человека, не сохраняя спокойствие самому, очень сложно. Если вас задело поведение руководителя и вы чувствуете, что готовы ответить ему тем же, возьмите паузу. Сделайте перерыв, уединитесь в спокойном месте, постарайтесь расслабиться и подождите, когда первая реакция пройдет. Только когда вы почувствовали, что сами готовы действовать конструктивно, переходите к следующему пункту.
2. Попросите руководителя уделить вам время и поговорить наедине. Очень важно начинать разговор о деликатных темах один на один, в месте, где никто больше не будет вас слышать. Разговор о собственных проблемах это всегда неприятно, но когда эту тему поднимают при подчиненных, это особо задевает и подрывает авторитет, что заставит сразу защищаться и оттолкнет человека от вас.
3. Когда вы оказались наедине, поинтересуйтесь, как идут дела. Скажите, что видите, что ситуация тяжелая и спросите не можете ли вы как-то помочь.
4. Постарайтесь рассказать, как все члены вашей команды стараются и как для всех вас важно, чтобы вы все успели в срок. Руководители часто большую часть времени проводят на встречах и могут не успевать оценить как работает команда в их отсутствие. Ощущение, что команда на твоей стороне и старается помогает приобрести уверенность. При этом не будьте голословными, подтвердите свои слова примерами, вспомните когда ваши коллеги делали что-то сверх ожидаемого, покажите метрики.
5. Осторожно объясните, как его неправильное поведение влияет на команду. Также можно привести примеры того, как падает мотивация, после таких случаев. Однако будте осторожны приводя в пример просадку мотивации своих коллег, это может быть воспринято как сигнал о нерадивом сотруднике. Смотрите по ситуации, насколько руководитель готов воспринимать эту информацию адекватно.
6. Если вы понимаете, что ваш руководитель перегружен и он попросит помощи, попробуйте взять на себя часть работы и разделить ее с коллегами. Помните о том, что тимлид делает очень много, казалось бы невидимой, работы, о которой вы можете не знать и которую может сделать только он. Выбивание ресурсов, согласование повышений, отчеты перед руководством, проработка будущих проектов, улаживание конфликтов и так далее и тому подобное. Это все может занимать много времени и сил. Однако есть задачи, часть которых разработка сможет взять на себя, это освободит время тимлида и остальная команда от этого только выиграет.

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

Хотите, чтобы мы разобрали ваш кейс? Присылайте их на нашу почту info@itleadassist.io и мы опубликуем разборы на них в канале.

#разборкейса

Ваш ПО делает все, чтобы контролировать вашу работу? Мы знаем как ему помочь и при этом сделать работу всего отдела максимально комфортной. Поделитесь с ним, чтобы человек не мучался.

#владельцу_продукта

https://oros-it.ru/blog/how-to-use-metriks-for-it-team-work?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Навигация по каналу

У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.

#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io

#чеклист - бесплатные чеклисты

#agile_который_работает - материалы по Agile в том виде, который реально работает

#настройка_процессов - материалы по процесса в команде

#построение_команды - все о построении команды, от структуры до обязанностей каждой должности

#владельцу_продукта - все что будет полезно для представителей бизнеса

#тимлиду - все что будет полезно тимлиду и любому руководителю

#советы - рубрика советов и статьи с советами

#ответы_на_вопросы - ответы на ваши вопросы

Рубрика “Разбор кейсов”
Формула убеждения

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

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

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

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

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

Работа с несогласными
Но если вы самостоятельно принять решение о внедрении вашей идеи не можете, тогда вас ждет дополнительная работа.

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

Если и после второго круга вам договорится не удалось, то придется запастись терпением и повторять следующий алгоритм:

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

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

Хотите, чтобы мы разобрали ваш кейс? Присылайте их на нашу почту info@oros-it.ru и мы опубликуем разборы на них в канале.

#разборкейса

Проект летит ко всем чертям, а бизнес не понимает почему вы хотите все переписать? Хотите узнать, как спасти проект? Есть решение! Но придется немного подготовится. Обо всем по порядку, но начните с метрик.

#тимлиду #владельцу_продукта

https://oros-it.ru/blog/refactoring-for-it-and-business?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

Спорим, что, прочитав эту статью, вы точно захотите так работать, немедленно отправите ее своему ПО и начнете делать все самостоятельно? 😉

#владельцу_продукта

https://oros-it.ru/blog/self-organized-teams-with-help-of-PO?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Как расти джуну-разработчику

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

Итак приступим. Для начала ответим на вопрос за что мы ценим джунов? За то что мало стоят. Самое важное в джунах горящие глаза и желание учится. Они еще не устали от рутинных задач, им можно поручить текучку и они все равно смогут на ней расти. Хороший джун это ценный материал, из которого можно сделать отличного работника именно под ваши нужды. Поэтому главное, что нужно помнить джуну - знайте свое преимущество и используйте его.

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

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

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

Делитесь со своими знакомыми джунами, давайте вместе сделаем текущий рынок чуточку лучше.

#чеклист

Вот бы людей в отдел побольше, человек так 40-50... 😃 Давайте обсудим чем грозит разрастание отдела. Можно ли быть "большим начальником" и при этом работать эффективно? Что делать, если все таки команда стала слишком большой и неуправляемой? Увольнять никого не придется, не переживайте.

#тимлиду

https://oros-it.ru/blog/agile-team-size?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

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

#чеклист

Как правильно трактовать Agile-манифест
Часто неправильная трактовка Agile-манифеста вредит работе команды, приводит к неправильному построению процессов, переработкам и падению качества продукта. Поэтому очень важно не просто знать Agile-манифест, а уметь правильно его трактовать, чтобы он помогал строить эффективную работу над действительно правильным продуктом. Поэтому в нашей рубрике #agile_который_работает мы будем разбирать основные идеи и принципы Agile в ключе правильного построения работы. Начнем с общих подходов, которые нужно использовать при трактовке Agile-манифеста, а в следующих постах подробно разберем каждый пункт.

Одно не исключает другое
Во всех основных идеях манифеста мы читаем противопоставление, на пример: “люди и взаимодействие важнее процессов и инструментов”. И это “важнее” многих сбивает с толку. Частая ошибка заключается в том, что основные идеи трактуются как “одно исключает другое”. И это совершенно неверно. Ни в одной основной идея Agile одно не исключает другое. Они лишь расставляют приоритеты в спорных ситуация (не в каждодневной работе), но не говорят о том, что в Agile не должно быть процессов (весь Agile в общем-то помогает строить процессы) или о том, что вы должны отменить все свои официальные контракты. Без процессов и документооборота работа не строится и не должна. Agile это всегда про гибкость и именно ее отражают основные идеи. Позже мы разберем каждую из них подробнее, сейчас лишь сформулируем основную мысль: основные идеи Agile не про исключение, они про гибкость.

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

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

Основная идея Agile - гибкость, ничто не должно противоречить ей
Agile в своем названии не просто так отражает гибкость. Это сама основа Agile. И манифест в первую очередь строится таким образом, чтобы помочь развернуть мышление в нужную сторону. Но чтобы не запутаться в трактовке манифеста всегда нужно помнить основную мысль, что работа должна строится на гибкости. Это значит, что взяв за основу основные фреймворки Agile вы должны в первую очередь смотреть на то работает ли все это для вашей конкретной команды. И если что-то для нее не работает, то оно должно гибко подстраиваться под вашу конкретную ситуацию. Если, на пример, вы работаете с людьми, которые не могут работать в личном взаимодействии и постоянно нарушают договоренности, то отменяйте для себя этот принцип, потому что он для вас не работает. Ставьте на первое место жесткие процессы и документирование любых договоренностей, потому что для вас это работает только так (по крайней мере на данном этапе). Потому что самый важный принцип Agile - гибкость, с помощью которой он идеально адаптируется под любые ситуации.

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

А потренироваться в этом вы пожете прямо сейчас на интервью с одним из основателей нашего проекта Максимом Шаламовым, который поделился своими мыслями о пути от разработчика до СТО крупных нагруженных проектов и дал советы о том, что нужно помнить, чтобы пройти этот путь проще и быстрее. Даже, если вы не планируете стать руководителем, то сможете подсмотреть, как думает ваше руководство. Скорее хватайте блокнот для записей и переходите по ссылке 👇

https://oros-it.ru/blog/career-path-from-developer-to-cto?utm_source=tg&utm_medium=article&utm_campaign=tg_post

#тимлиду

Как не превратить проваленные сроки в конец света

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

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

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

- сделайте оценку на сколько вы не успеваете;

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

- сразу сообщите о проблеме своему руководителю. Чем раньше вы подсветите проблему, тем больше шансов повлиять на ситуацию;

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

- если задача имеет высокий приоритет в спинте и перенос ее сроков нежелателен, то обсудите с руководителей и/или командой, можно ли перетасовать другие задачи, чтобы кто-то смог вам помочь уложиться в поставленные сроки;

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

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

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

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

#разборкейса