Архив рубрики ‘Управление разработкой’

Я передавал задачи в другие отделы — но их никто не делал. Всё исправили 5 процессов

В одной компании мы передавали задачи между отделами в чатах. В другой — по почте. Где-то использовали таблицы. Схемы отличались, результат был один и тот же.

Организация производства Информационных систем. Часть 1. Предмет исследования

I   ВВЕДЕНИЕ

Три зоны ответственности тимлида: спринт, команда и продукт

Когда я пришёл в последнюю компанию тимлидом, первое время ушло на знакомство с командой, ближайшими планами, запуском проекта и задачами адаптации. Через пару недель стало понятно, что пора организовывать работу команды вокруг развития продукта и людей. Я опирался на предыдущий опыт и составил для себя чек‑лист, который разложился на три блока: спринт, команда и продукт.

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

Привет, Хабр! Меня зовут Антон, я руковожу направлением автоматизации тестирования BIOS/BMC в YADRO. Как-то раз я моргнул — и наша команда из 10 инженеров выросла до 35. Вместе с этим у нас появились направления и лиды, а значит, я больше не могу прийти в любую задачу и сам ее быстро закрыть.

Кто такие CTO, CIO и COO?

Когда я рос из инженера в управленца, мне казалось, что различия между CTO, CIO и COO во многом формальные. Всё же «про технологии», «про управление», «про процессы». На практике оказалось, что это три разных способа смотреть на компанию. И путаница между ними начинает дорого стоить именно тогда, когда бизнес перестаёт быть маленьким.

Карго-культ в Jira: Почему метрики растут, а продукт гниет (Эффект Хоторна)

(картинка сгенерирована Nano Banana) Есть такой специфический момент в жизни любой IT-компании, обычно за неделю до закрытия квартала. Графики в дашбордах вдруг начинают выглядеть подозрительно хорошо.

Merge Request как транзакция

В этой заметке описана концепция организации производства ПО «Merge Request как транзакция изменения системы, и где в ней возникает eventual consistency». Имеется положительный опыт применения данной концепции на большом общероссийском проекте со сложным процессом производства ПО. Здесь же, в качестве примера, мы будем рассматривать её на большом абстрактном проекте, который описан ниже. Данная концепция приносит […]

Процессы vs. Инструменты: как выстроить сквозной поток создания ценности

Недавно мы с командой посчитали, сколько времени уходит только на то, чтобы найти информацию о задаче. Получилось около 8 часов в неделю на человека — это целый рабочий день, который тратится на переключение между Jira, Excel, почтой, Service Desk, GIT,  Confluence и ещё парой внутренних систем. При этом половина контекста всё равно теряется где-то между […]

Vanilla dev., Framework, CMS, конструктор или AI – что выбрать для разработки веб-приложения

Полагаясь на свой опыт работы в качестве веб-разработчика написал небольшую статью, по большей части рассчитанную на менеджеров IT-компаний, SEO-специалистов и младших веб-разработчиков. Если будущее приложение представляет из себя CLI-утилиту или является частью микросервисной архитектуры как отдельный микросервис, то разумно ограничить выбор достаточного инструмента для разработки языком программирования (vanilla development) или микрофреймворком.

Лучшие практики для бизнеса из профессионального спорта. Часть 1: Разбор полетов

Продолжаю цикл статей о том, что традиционный бизнес обязан подсмотреть и забрать себе из практик профессиональных игровых видов спорта (потому что спорт, внезапно, оказывается сложнее и умнее). Нулевая, вводная часть выложена здесь, а сегодня мы разберем, зачем нужно то, что называется словами Post-game review, Post-season Review, After Action Review или «Разбор полетов».