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

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

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

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

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

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

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

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

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

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

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

#тимлиду

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

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

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

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

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

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

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

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

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

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

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

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

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