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

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

- сроки;
- ресурсы;
- потребность в остановке выпуска нового функционала;
- на какие метрики влияет рефакторинг;
- планируемые шаги.

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

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

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

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

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

А вот такой Nyan Cat пример того, что можно сделать с помощью этого генератора пиксельной графики. Его код можно скопировать и вставить куда угодно на свой сайт.

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

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

https://oros-it.ru/blog/five-steps-for-effective-stendup?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

#советы

https://youtu.be/L0vQDsRdsj0

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

#тимлиду

https://oros-it.ru/blog/do-you-need-to-rise-problem-employee?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Рубрика "Советы СТО"
Не пускайте дела на самотек

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

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

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

#советы

Иногда размер таблиц в PostgreSQL необъяснимо растет при апдейтах. Мы разобрались почему это происходит и как это работает, а также рассмотрели общие моменты работы транзакций и MVCC. Эта проблема будет особенно актуальна для тех у кого очень частые изменения записей в таблицах, если это как раз ваш случай, то обязательно прочтите эту статью, чтобы избежать проблем.

https://oros-it.ru/blog/why-postgresql-table-grow?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Рубрика “Разбор кейсов”
Сотрудники не хотят проведения стендапов

Кейс
Участники команды яро протестуют против проведения стендапов и отказываются на них ходить.

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

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

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

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

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

Недавно новое Temporal API прошло третью стадию технического комитета TC39 для добавления в стандрат языка JavaScript. Мы сняли для вас небольшой обзор с тем как можно попробовать это API. А так же мы готовим большой материал по сравнению нового API с текущими возможностями Date. Подписывайтесь на наш канал в телеграмм, чтобы ничего не пропустить.

https://youtu.be/m53udgMpkco

Ведущему разработчику бывает сложно понять куда стоит двигаться дальше на его позиции и что еще важно для дальнейшего роста. Не всегда рядом есть руководитель, который умело направит и расскажет на что делать упор. В новом подкасте СТО Максим Шаламов и руководитель направления frontend Ренат Саматов, вырастившие под собой десятки людей, рассуждают на тему того, что необходимо ведущему, чтобы двигаться дальше.

https://youtu.be/5Wf1A5vfylw

В продолжение темы Temporal API в JavaScript мы подготовили для вас подробное сравнение основных возможностей Temporal и Date с примерами кода.

https://oros-it.ru/blog/javascript-temporal-vs-date?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

#тимлиду

https://www.youtube.com/watch?v=PrC-OfcsTPQ

Сегодня поговорим о том, как владельцу продукта (ПО) наладить контакт со своей командой разработки. Поговорим про то, как стоит действовать и чего стоит избегать, чтобы получить доверие команды. Делитесь со своими ПО, чтобы проверить, знают ли они эти правила?

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

https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

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

https://youtu.be/8f8vMChEdT8

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

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

https://oros-it.ru/blog/who-is-responsible-for-release?utm_source=tg&utm_medium=article&utm_campaign=tg_post

Рубрика “Разбор кейсов”
Конкретный сотрудник пропускает стендапы

Кейс
Один конкретный участник команды пропускает ежедневные стендапы.

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

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

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

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

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

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

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

Хороший способ разобраться с анимацией на CSS это посмотреть реализацию простых лоадеров. Мы собрали для вас 5 решений от простого к сложному и подробно разобрали их реализацию. А если вам как раз нужен лоадер для вашего сайта, то смело копируйте код из статьи.

https://oros-it.ru/blog/loaders-animation-on-css?utm_source=tg&utm_medium=article&utm_campaign=tg_post

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

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

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

#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