#рецепт
Какие бывают низковисящие фрукты в выстраивании процессов в it?
Привет, читатель!
Давай немного пофантазируем. Представь что ты руководитель проектов и пришел в новый стартап, который разрабатывает веб-сервис, аналог букинг
Процессов в этой компании нет, а ты опытный менеджер. Какие можно сделать очевидные улучшения в работе, которые будет просто внедрить, но они быстро принесут пользу, улучшат работу в компании и заработают для тебя уважение?
Вот мои мысли на этот счет:
1. Внедри тасктрекер и запускай технофашизм. Даже если людям не ок на старте и будет открытое сопротивление, у тебя появится наблюдаемость кто и что делает, у кого задачи и тд;
2. Причеши бэклог до управляемого вида:
a. Внедри строгую типизацию задач по природе работы. Отдельно улучшения функциональности (фичи), улучшения эксплуатации (технологические улучшения/энейблеры/техдолг), несоответствия ожиданиям работы (дефекты/баги) и процессное (например, написать регламент выкатки релизов). Типов может быть больше, но минимум 4;
b. Внедри размерность задач. Отделить очень большие задачи (эпики), от средних (стори/фичи/пакеты) и от мелких (подзадачи/таски);
c. Установи обязательные поля для каждого типа задач. Есть общие характеристики, например создатель или описание, а есть разные например способ воспроизведения у дефекта;
d. Внедри любую модель приоритизации. Главное отделить СРОЧНОНАДОСДЕЛАТЬ (асапы, криты) от обычных задач и приписать критерии для них. Введи правило что делать с такими задачами.
3. Если у ТП нет сервисдеска - внедри любой, ну или загони также в таск трекер, это лучше чем на коленке и в личных сообщениях разработчиков;
4. Научи ТП передавать тикеты по форме "ожид. результат, факт. результат, способов воспроизв., кол-во лицензий/пользователей, устройства/гео";
5. Внедряй разбор дефектов. Вот 3 принципа:
a. Не все задачи от ТП дефекты. Некоторое хотелки. Отделяй одно от другого и раскладывай на разные кучки. Научи этому ТП;
b. Не все дефекты срочные и важные. Опиши какой функционал критичный, а какой нет. Опиши какое кол-во пользователей/лицух важно, а какое не очень. Внедри понятия severity и priority. Научи тп пользоваться матрицей из них для определения класса критичности дефекта;
c. Дефекты не живут долго. Дефект который может подождать пол-года не нужен, его можно просто удалить.
6. Введи практику postmortem по инцедентам. Потом и в ретро может перерасти;
7. Проведи аудит коммуникаций. Выясни у кого есть какие встречи. По каждой встречи опиши (для себя) в чем ее цель, какие входы, какие выходы, какие участники, типовая агенда. Построй что-то вроде data flow diagram, чтобы понять как информация между встречами курсирует. Эта информация даст много поводов для улучшений, вроде закрытия ненужных встреч;
8. Начни распространять простые регламенты. Не обязательно своими руками. Правила код-стайла, как проводить код ревью, как апрувить мр это туда же;
9. Научи писать release notes. Круто будет научить на них смотреть ТП и отдел обучения;
10. Запусти 1-1 со своими подчиненными. Начни писать для себя их досье, в нем описывай их сильные стороны и старайся регулярно хвалить. Будет круто если твои подчиненные начнут также делать со своими сотрудниками;
11. Запусти статус-встречи. В целом по направлению, как у вас дела, что нового, какие планы на будущее и обязательный раздел под вопросы и ответы. Вовлеченность поднимет;
12. Максимально уменьши количество каналов коммуникации для рядовых сотрудников, например разработчиков, максимально замыкай на менеджеров;
13. Выдели горизонт тактического планирования. Например, 2 недели. Начни смотреть сколько планировали сделать за 2 недели, а сколько сделали на самом деле и задаваться вопросом “а что помешало?”. Начни удалять эти “помешало”
А какие еще ты видишь очевидные улучшения, которые легко провести? Чтобы ты еще добавил в этот список? Напиши в комментариях!
Какие бывают низковисящие фрукты в выстраивании процессов в it?
Привет, читатель!
Давай немного пофантазируем. Представь что ты руководитель проектов и пришел в новый стартап, который разрабатывает веб-сервис, аналог букинг
Процессов в этой компании нет, а ты опытный менеджер. Какие можно сделать очевидные улучшения в работе, которые будет просто внедрить, но они быстро принесут пользу, улучшат работу в компании и заработают для тебя уважение?
Вот мои мысли на этот счет:
1. Внедри тасктрекер и запускай технофашизм. Даже если людям не ок на старте и будет открытое сопротивление, у тебя появится наблюдаемость кто и что делает, у кого задачи и тд;
2. Причеши бэклог до управляемого вида:
a. Внедри строгую типизацию задач по природе работы. Отдельно улучшения функциональности (фичи), улучшения эксплуатации (технологические улучшения/энейблеры/техдолг), несоответствия ожиданиям работы (дефекты/баги) и процессное (например, написать регламент выкатки релизов). Типов может быть больше, но минимум 4;
b. Внедри размерность задач. Отделить очень большие задачи (эпики), от средних (стори/фичи/пакеты) и от мелких (подзадачи/таски);
c. Установи обязательные поля для каждого типа задач. Есть общие характеристики, например создатель или описание, а есть разные например способ воспроизведения у дефекта;
d. Внедри любую модель приоритизации. Главное отделить СРОЧНОНАДОСДЕЛАТЬ (асапы, криты) от обычных задач и приписать критерии для них. Введи правило что делать с такими задачами.
3. Если у ТП нет сервисдеска - внедри любой, ну или загони также в таск трекер, это лучше чем на коленке и в личных сообщениях разработчиков;
4. Научи ТП передавать тикеты по форме "ожид. результат, факт. результат, способов воспроизв., кол-во лицензий/пользователей, устройства/гео";
5. Внедряй разбор дефектов. Вот 3 принципа:
a. Не все задачи от ТП дефекты. Некоторое хотелки. Отделяй одно от другого и раскладывай на разные кучки. Научи этому ТП;
b. Не все дефекты срочные и важные. Опиши какой функционал критичный, а какой нет. Опиши какое кол-во пользователей/лицух важно, а какое не очень. Внедри понятия severity и priority. Научи тп пользоваться матрицей из них для определения класса критичности дефекта;
c. Дефекты не живут долго. Дефект который может подождать пол-года не нужен, его можно просто удалить.
6. Введи практику postmortem по инцедентам. Потом и в ретро может перерасти;
7. Проведи аудит коммуникаций. Выясни у кого есть какие встречи. По каждой встречи опиши (для себя) в чем ее цель, какие входы, какие выходы, какие участники, типовая агенда. Построй что-то вроде data flow diagram, чтобы понять как информация между встречами курсирует. Эта информация даст много поводов для улучшений, вроде закрытия ненужных встреч;
8. Начни распространять простые регламенты. Не обязательно своими руками. Правила код-стайла, как проводить код ревью, как апрувить мр это туда же;
9. Научи писать release notes. Круто будет научить на них смотреть ТП и отдел обучения;
10. Запусти 1-1 со своими подчиненными. Начни писать для себя их досье, в нем описывай их сильные стороны и старайся регулярно хвалить. Будет круто если твои подчиненные начнут также делать со своими сотрудниками;
11. Запусти статус-встречи. В целом по направлению, как у вас дела, что нового, какие планы на будущее и обязательный раздел под вопросы и ответы. Вовлеченность поднимет;
12. Максимально уменьши количество каналов коммуникации для рядовых сотрудников, например разработчиков, максимально замыкай на менеджеров;
13. Выдели горизонт тактического планирования. Например, 2 недели. Начни смотреть сколько планировали сделать за 2 недели, а сколько сделали на самом деле и задаваться вопросом “а что помешало?”. Начни удалять эти “помешало”
А какие еще ты видишь очевидные улучшения, которые легко провести? Чтобы ты еще добавил в этот список? Напиши в комментариях!