Как правильно трактовать 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 и любых используемых в вашей команде средств. Так вы избежите ситуации, что о проблеме узнают только в конце сроков и вы не сможете доказать, что поднимали этот вопрос вовремя;

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

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

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

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

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

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

Универсальная структура ИТ-отдела

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

#тимлиду

Как быть неформальным лидером

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

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

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

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

В случае, если вам интересно взять на себя эту дополнительную работу по управления командой, то обязательно сделайте следующее:

- попросите анонс перед участниками процесса о том, что вы будете помогать по конкретному направлению;

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

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

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

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

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

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