IT 2

1. IT 2.0 Избавление от хаоса

Пересмотр IT отдела на корневом уровне

2. Хаос который был неизбежен

Задачи строились исходя из желаний коллег и собственного удобства, будь я им
Никаких ТЗ – что порождало вечные правки и багфиксы в процессе, отсюда следует,
что система поддерживалась, а не строилась
Не разработанная система планирования и чёткой архитектуры

3. Дедлайн, как способ давления микроменеджментом

Смещение фокуса с качества на дату
Начинается многозадачность, чтобы успеть в срок
Появляется скрытый технический долг
Выгорание от вечных мыслей о сроках и страха не успеть

4. Квартальные задачи вместо дедлайнов

Что нам это даёт:
Меньше срочных правок – больше времени на архитектуру
Создание метрик и сухих цифр в конце квартала
Голова работает с одной задачей за раз, нет вечного давления «сейчас-срочно»
Можно перераспределять усилия внутри квартала без хаоса

5. Рабочие взаимодействия

6. Правила взаимодействия

Как мы будем работать с задачами:
Все детали и требования обсуждаются только на этапе подготовки ТЗ
Никаких сообщений: “Было бы круто сделать это прямо сейчас” после составление ТЗ
7–14 дней на составление полного ТЗ без оставшихся вопросов
Результат:
Минимизация правок
Ускорение процессов
Повышение качества
Без чёткого ТЗ – результат ХЗ

7.

Теперь о стандартах

8. Стандарт выполнения задачи

Для поддержания надёжности и отказоустойчивости в
случае чего, IT отдел будет придерживаться такого потока
выполнения одной задачи. Т.е.
Берётся задача ->
Разрабатывается ->
Реализовывается ->
Тестируется ->
Документируется ->
Закрытие задачи
На выходе получаем протестированную и стабильную часть
проекта с документацией

9. Стандарт приоритетов тикетов (WIP)

Тикет – не задача
Тикет – это какая то правка, баг или ошибка связанная
исключительно с продуктом в IT отделе. При возникновения
желания написать тикет, человек обязан писать его в
PLANKA, никаких других способов сообщения о проблемах
не должно быть (За исключением критических тикетов)
Каждый тикет имеет свой уровень важности с чётким
описанием условий и сроков выполнений

10.

Бизнес-риски

11. Единственная точка отказа

Все ключевые знания сосредоточены в
одном человеке
Архитектура, код, инфраструктура,
процессы — без дублирования
Я
IT
При недоступности (болезнь, увольнение
или выгорание) — остановка разработки
критических и сложных частей, а так же
невозможность исправлений ошибок
Один человек закрывает несколько
вакансий
МП
Прои
звод
ство

12. Роль техлида

Что я делаю сейчас:
Архитектура системы
Разработка (C++, JavaScript)
Проектирование процессов
Построение IT-отдела с нуля
Поддержка продуктов
Это роль технического лидера, а не просто разработчика

13. Текущий рынок по ролям в IT

Роль
Обязанности
Диапазон ЗП
Middle JS
Выполнение задач
50 000 – 90 000 руб
Senior JS
Архитектура, код, качество
100 000 – 130 000 руб
Tech Lead
Архитектура, процессы, лидерство
110 000 – 140 000 руб
Данные взяты с hh.ru по небольшим регионам
с численностью на уровне Тольятти

14. Почему это важно для компании

Снижение рисков
Удержание разработчиков в компании
Экономия денег компании
Соответствующая оплата по схеме:
Ответственность = Компенсация по рынку
Рыночная ЗП
Сохранение
компетенции
Уменьшение
рисков
Экономия при
найме новых
сотрудников
Предотвращение
выгорания

15.

Выводы

16.

1. Разработан каркас системной модели работы IT
отдела
2. Устойчивость IT системы напрямую зависит от
мотивации и вовлечённости ключевых специалистов