Как стать автором
Обновить
285.73

Управление разработкой *

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

Тайное искусство оптимизации процессов

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 5.8K

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

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

Читать далее
Всего голосов 20: ↑12 и ↓8 +4
Комментарии 6

Всё, везде и сразу про управление командами

Уровень сложности Простой
Время на прочтение 15 мин
Количество просмотров 4.9K

Я тимлид в IT команде и я люблю читать. 5 лет назад я прочитал Фредерика Лалу «Открывая организации будущего». Потом Патти МакКорд «Сильнейшие. Бизнес по правилам Netflix». Потом еще 5 книг около менеджмента. И каждая книга меняла меня. Но с каждой новой я все более критично относился к предыдущим. Я всегда делал заметки с главными идеями книг и пробовал их в своих командах. В итоге в голове смешались мысли из всех источников. Горе от ума, если можно так сказать. Ничего не знать или знать много, но не структурировано - это практически одно и то же для меня.

Месяц назад я выписал подходы из всех источников себе на whiteboard. И пропустил их все через призму своего восприятия. Выделил общее, разное и тут готов вам рассказать про своё приключение. Считай, мета-анализ главных посылов из книг про управление командами.

Читать далее
Всего голосов 15: ↑12 и ↓3 +9
Комментарии 1

Иногда лучше делать, а не планировать

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 42K

Пожилой рабочий на строительстве «Эмпайр-стейт-билдинг» в 1930 г., источник. Вся стройка от подготовки стройплощадки до торжественного запуска лифтов заняла 410 дней

В последнее время часто приходится слышать про новую модель управления — избыток административных кадров, не имеющих отношения к основному производству. К сожалению, это особенно ярко проявляется в IT-индустрии, где количество менеджеров среднего звена сильно превышает стандартные показатели. Например, в компании Google доля менеджеров уже достигла 15% от общей численности персонала, то есть по одному менеджеру на пять-шесть работников. Это заметно превышает средний показатель в сфере услуг 1 к 15.

Избыток менеджеров в компании ведёт к негативным последствиям:

  • засилье KPI с последующей деградацией продукта, которое по менеджерской логике должно увеличивать DAU;
  • деградация корпоративной культуры из-за офисных интриг и карьеризма;
  • снижение продуктивности разработчиков из-за бесконечных совещаний, созвонов, отчётности и использования ПО для «повышения эффективности» (таск-трекеры, тайм-трекеры, календари и проч.);
  • цифровое истощение и выгорание сотрудников.

Это стандартные издержки от переизбытка менеджеров. Иногда даже единственный менеджер приносит больше вреда, чем пользы.
Читать дальше →
Всего голосов 186: ↑175 и ↓11 +164
Комментарии 103

Почему OKR — это отстой

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 23K

Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.

Читать далее
Всего голосов 59: ↑53 и ↓6 +47
Комментарии 26

Истории

Что делать в первую очередь? Простая приоритизация задач при помощи риса

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 7.4K

Реализация проекта или создание продукта связаны с выполнением задач, тестированием идей и гипотез. Зачастую их накапливается огромное количество, и встает извечный вопрос (нет, не кто виноват и что делать): что делать в первую очередь? Если в организации не установлены явные правила, то будет работать «правило джунглей»: прав тот, кто громче кричит. Соответственно, с наивысшим приоритетом пойдут задачи того, заказчика, который имеет перевес в голосе и в «корпоративном весе».

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

Читать далее
Всего голосов 15: ↑11 и ↓4 +7
Комментарии 7

Кто такой PM и с чем его едят (для самых маленьких)

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 11K

Меня зовут Александр, и я тяну свою лямку менеджером проектов уже чуть больше 4-х лет. Еще на заре своей пока еще мини‑карьеры у меня возникло желание на своем опыте рассказать про свою профессию и ее нюансы. И вот — теперь желание совсем уж сформировалось.

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

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

Читать далее
Всего голосов 12: ↑8 и ↓4 +4
Комментарии 14

Какие навыки помогут стать хорошим тимлидом

Время на прочтение 13 мин
Количество просмотров 4.6K

Привет, Хабр! Мы в beeline cloud развиваем вАЙТИ — новое DIY-медиа для ИТ-специалистов, в котором собираем практические истории экспертов из различных компаний про решение самых разных ИТ-задач. Если вы накопили достаточно опыта и хотите им поделиться, приходите к нам в медиа. За вклад в развитие вАЙТИ каждый автор получает денежное вознаграждение.

Сегодня в выпуске история Александра — он расскажет о навыках, которые помогут стать хорошим тимлидом.

Читать далее
Всего голосов 8: ↑4 и ↓4 0
Комментарии 3

Обзор продуктивности разработчиков от McKinsey

Время на прочтение 14 мин
Количество просмотров 2.6K

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

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

Читать далее
Всего голосов 25: ↑21 и ↓4 +17
Комментарии 3

Тимлид, которого не любят

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 21K

Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.

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

Читать далее
Всего голосов 28: ↑21 и ↓7 +14
Комментарии 23

Почему нанимать только сеньоров — проигрышная стратегия

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 14K

У каждой компании свои оправдания:

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

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

В крупных компаниях: "У нас очень сложная инфраструктура, джунам потребуется слишком много времени, чтобы освоить ее".

Это полная чушь.

Читать далее
Всего голосов 32: ↑16 и ↓16 0
Комментарии 61

LeadHub Сравни: как лиды придумывают точки роста для процессов в компании

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 816

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

Звучит отлично – в теории.

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

Когда-то так было и у нас. Сейчас – все 30 участников высказываются по очереди, формируют рабочие группы по внедрению улучшений, разносят итоги встреч по своим командам.

За 2.5 года мы прошли путь от “лиды молча послушали рассказ о том, как космические корабли бороздят просторы большой стратегии” до “ребята сами придумали и реализовали точки роста, которые помогли компании сэкономить миллионы рублей”. 

Как развивался формат общих встреч лидов в Сравни – читайте в этой статье. 

Читать далее
Всего голосов 18: ↑14 и ↓4 +10
Комментарии 0

Это реально? Что должен уметь джуниор системный аналитик по профессиональному стандарту Минтруда России

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 19K

Нам оставили немало комментариев к статьям по подготовке к собеседованию системного аналитика (СА) о том, что примеры со сложными вопросами по SQL, REST и диаграммам — избыточны. И что СА не обязан знать, как написать код обработки запроса на Python, И даже СУБД — тоже не сфера знаний СА, как и много другое. А что же обязан знать и уметь СА? Давайте пройдемся по новому профессиональному стандарту «Системный аналитик» от Минтруда РФ и возьмем требования для грейда «джуниор СА». Вам откроется немало удивительного. Правда, есть пункт, не вызывающий сомнений: «Русский язык в объеме, необходимом для выполнения трудовой функции».

Читать далее
Всего голосов 16: ↑13 и ↓3 +10
Комментарии 34

Как все, что вы построили своими руками, разрушить руками своих сотрудников? 5 проверенных методов

Время на прочтение 5 мин
Количество просмотров 18K

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

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

В этих мечтах нет ничего зазорного.

Читать далее
Всего голосов 23: ↑8 и ↓15 -7
Комментарии 5

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн

Техдолга не существует

Время на прочтение 9 мин
Количество просмотров 7.4K

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

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

Читать далее
Всего голосов 38: ↑28 и ↓10 +18
Комментарии 33

Задача готова! Или нет? Definition of Done и зачем он нужен

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 5K

Менеджер: Эта задача готова?
Разработчик: Да.
Менеджер: Давайте катить на пользователей?
Разработчик: Давайте.
Менеджер: Что‑то не вижу функциональности на продакшене?
Разработчик: Ну, нам нужно еще пару дней — пройти код‑ревью, подождать, чтобы QA протестировали, собрать и выкатить релиз в прод, сделать несколько миграций данных, и потом мы откроем фичу для пользователей.
Менеджер: Но ты же сказал, что задача готова?
Разработчик: Да.

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

Читать далее
Всего голосов 16: ↑15 и ↓1 +14
Комментарии 13

Горизонтальные связи и ролевая модель большой команды

Уровень сложности Простой
Время на прочтение 12 мин
Количество просмотров 5.3K

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Читать далее
Всего голосов 16: ↑14 и ↓2 +12
Комментарии 9

Лучшие практики RuStore: правила хорошего Code Review для Android

Уровень сложности Средний
Время на прочтение 6 мин
Количество просмотров 3.1K

Привет, я Михаил Емельянов, руководитель Android-направления в RuStore. Над стором трудится большая команда разработчиков, проект регулярно дорабатывается, а количество новых строк кода неизменно увеличивается. 

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

В этой статье расскажем, как мы построили процесс Code Review в RuStore, какую проблему решали, поделимся нашими практиками и сделаем выводы.

Читать далее
Всего голосов 37: ↑33 и ↓4 +29
Комментарии 9

Уже не программист, но еще не менеджер

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 11K

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

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

Читать далее
Всего голосов 29: ↑27 и ↓2 +25
Комментарии 19

Качество выше, релиз ближе: как аналитик влияет на успех IT-проекта

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 4K

Привет, я Юля Зубова — руководитель отдела аналитики в диджитал-агентстве ДАЛЕЕ. Хотя написано много статей про роль аналитиков, открыты сотни вакансий и есть даже целые сформированные отделы, остались компании и команды, где их нет. Иногда приходится объяснять, зачем нужны эти специалисты.

Расскажу, какую роль играет аналитик, на каких проектах он жизненно необходим, а на каких можно обойтись и без него.

Читать далее
Всего голосов 14: ↑11 и ↓3 +8
Комментарии 6

Призыв писать компактное ПО, версия 2024 года (с примером кода)

Уровень сложности Простой
Время на прочтение 11 мин
Количество просмотров 33K

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

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

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

Читать далее
Всего голосов 150: ↑147 и ↓3 +144
Комментарии 197

Вклад авторов

Работа