Как судебный пристав домечтался до ИТ

Спойлер: через пот, кровь и слёзы. История о том, почему ИТ — это не про счастье и инновации, а про покой и волю.

Меня зовут Евгений Шатунов, я руководитель проекта в компании БЕТА, и мы занимаемся упаковкой технологий машинного обучения (и не только) в дружественные клиентам бизнес-приложения. Но это сейчас.

А пять лет назад я был судебным приставом, на меня спускали собак, выходили с оружием, и к высоким технологиям я имел такое же отношение, как коридорный Тед к детям мексиканского гангстера в фильме «Четыре комнаты».

Хочу рассказать, как я дошел до такой жизни.

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

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

• Мне. Отрефлексировать наконец-то для себя этот опыт

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

• Мне. Стать популярным и брать деньги за рекламу :)

Когда я пришел, у меня было три ключевых скилла:

1. Опыт управления персоналом, до 200 человек единовременно. Из него вытекли хорошо отточенные навыки коммуникации и документооборота.

2. Опыт работы в качестве судебного пристава. Здесь тоже про документооборот и коммуникацию, только при другом градусе неадекватности и стресса. Есть структуры, где творческий подход и гибкие методологии – вопрос выживания :)

3. Работа в среде Linux. У меня в свое время был слабый нетбук, который умирал на Windows 7. И мне нужно было решить проблему с минимумом затрат. Так я освоил и полюбил консольный Linux, потеряв бонусом остатки страха перед кодом и терминологией разработчиков. Наверное, только благодаря этому адаптация в компании заняла у меня максимум 3 месяца.

и уж тем более не пересылать письма одних вторым, а обеспечивать своевременные ответы на правильные вопросы.

Здесь есть две стороны: вовремя получить ответ от заказчика (а если там собралась аж рабочая группа – то это целый квест) и получить адекватные сроки и обратную связь от разработчиков.

Был случай, когда нашла коса на камень, и мне пришлось совершить жесточайшую ошибку менеджера проектов. Я залез в код. Залез, поправил, вылез и спокойно выдохнул. Потом залез еще раз. И еще.

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

Мы прошли этап работы с разработчиками на аутсорсе. Наверное, его проходит каждая компания. Но с ростом понимаешь, что высокое качество продукта (а услуга по разработке ПО – это продукт) недостижимо с аутсорс-разработчиками. Разные часовые пояса (самое меньшее из зол), разные подходы к реализации, разная степень заинтересованности – работа с этими факторами выливается в конечном счете в дополнительные затраты: временные, денежные и эмоциональные.

Зато теперь я знаю 100 и 1 способ вычисления вранья по скайпу.

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

На практике это означает, что 5 человек в команде разработки не могут выполнить за неделю задач на 200 часов. Немалую часть времени они будут тратить на то, чтобы обдумать, как лучше реализовать ту или иную задачу. Если не учитывать это при планировании, то весь проект будет идти в режиме «нужно завтра». В начале и вам и заказчику будет приятно смотреть на план-график, но в итоге его проклянут все.

Да, возможно решить какие-то горящие вещи в авральном режиме. Однажды, например, нам нужно было сделать заказчику техническое задание за период новогодних праздников. Мы чуть не умерли, конечно, но сделали. А потом сделали соответствующие организационные выводы: ввели уровни критичности задач, которые теперь на старте озвучиваем клиентам, чтобы обеспечить максимальную прозрачность разработки.

Одно из правил, которое я усвоил в компании, это то, что в разработке нет вещей (бизнес-задач), которые на данном этапе технологического развития нельзя сделать. Возвращаясь к 100 и 1 способу выявления вранья – когда мне говорят, что вот этого сделать нельзя, это сразу звоночек. Либо человек не знает, а что гораздо чаще – ему лень разобраться или не интересно «копать». Здесь мы возвращаемся к проблеме качества продукта с аутсорсерами – у них нет такой мотивации.

Еще один признак – это общие слова вроде «долго, тяжело, непонятно». Мой первый вопрос – «сколько?» Насколько долго, насколько тяжело? Любая задача может быть оценена в часах, даже если это нестандартная (для кого-то) задача и ей нужно больше времени. Всегда можно увеличить срок, если речь идет о промышленной разработке и качестве реализации программного обеспечения.

Здесь мог бы быть абзац про покой и волю, к которым я пришел в ходе своего пути к управлению разработкой, но нет. Будет только популярный среди мамкиных миллионеров (что же, мой личный опыт это подтвердил) вывод о том, что главное, на что стоит смотреть в людях из так называемых софтскиллз, это вовлеченность и увлеченность. Хорошая команда – это люди, которым не все равно. И всё. Это единственная причина, почему у кого-то взлетает, а у кого-то нет.