Путь 1С-разработки. Не спеша, эффективно и правильно

Автор Никита Зайцев

Книга Никиты Зайцева aka WildHare — пример того, как можно систематизировать и упаковать в текстовый формат профессиональный опыт, накопленный за почти двадцать пять лет успешной инженерной практики. Познакомьтесь с концепцией разработки прикладного ПО через эффективность процесса на всех стадиях – от работы с ожиданиями и требованиями до сопровождения и технической поддержки. Все приведенные в книге принципы, правила и рекомендации базируются исключительно на личном практическом опыте автора. Книга была написана исходя из девиза, вынесенного в название – неспеша, эффективно и правильно.
Кому адресована эта книга? В первую очередь она будет интересна профильным специалистам, то есть людям, занятым в отрасли разработки прикладного ПО, как начинающим, так и зрелым профессионалам.
Техническим контекстом в книге является технологический стек «1С» – автор всю свою профессиональную жизнь провел именно в этом уголке IT-вселенной и оперирует областями знания, в которых абсолютно уверен, и готов отвечать за каждое сказанное слово. Но идеи, изложенные в книге, можно применять к любым другим технологическим стекам.

• Язык: Русский
• Издатель: Питер
• Дата выпуска: 23 янв. 2024 г.
• ISBN: 9785446121694

Предварительный просмотр книги

Об авторе

Никита Викторович Зайцев (a. k.a. WildHare) — инженер по разработке/эксплуатации автоматизированных систем управления информацией, имеет сертификат 1С «Эксперт по технологическим вопросам крупных внедрений».

За 25 лет профессиональной деятельности прошел путь от программиста-разработчика до технического директора и системного архитектора. Работал в разных прикладных областях — от самых простых до систем «уровня города». Например, участвовал в проекте внедрения УАИС БУ «Облачная бухгалтерия города Москвы», был архитектором и ведущим разработчиком облачной подсистемы «1С:Фреш».

В течение почти всей карьеры сочетал производственные задачи и публицистическую деятельность в области IT: был ведущим популярного технического сайта, вел блог, опубликовал более десятка статей в журнале PC Magazine.

В настоящее время занимается консультированием и преподавательской деятельностью (в том числе в МФТИ и ВШЭ). Ведет технический подкаст «Радио 1С Энтерпрайз» (t.me/radio1c).

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [e-mail] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Предисловие

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

Когда мы, инженеры, сталкиваемся с чем-то незнакомым и непонятным, то обычно задействуем очень простой метод, который с некоторой долей иронии можно назвать «методом имени Генри Деринджера»¹, а именно — задаем себе два элементарных вопроса: а) «Что это?» и б) «Зачем?». То есть очерчиваем область определения и прорабатываем целеполагание. Если определение не вызывает откровенного недоумения, а целеполагание можно признать позитивным, значит, с данной конкретной сущностью можно иметь дело.

Первый вопрос — «Что представляет собой эта книга?». Можно пуститься в пространные рассуждения вроде «конечно, это не учебник в привычном смысле, но все-таки…», но мы постараемся обойтись без попыток определения через отрицание. Несомненно, эта книга является учебником, но только с одной очень важной оговоркой — это учебник для высшей школы.

Если бы перед автором поставили производственную задачу — прочитать академический курс по специальности «Разработка бизнес-приложений на платформе 1С:Предприятие», первым делом следовало бы написать именно эту книгу, чтобы она легла в основу курса. Звучит слегка самонадеянно, но автору есть с чем сравнивать: те преподаватели, которые в основу обучения закладывали собственные идеи и материалы, действительно были лучшими.

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

Сопоставляя различные идеи и точки зрения, будущий инженер начинает осваивать профессию, а действующий — расширяет кругозор и повышает свою квалификацию. Собственно, именно этот процесс мы и называем «высшей школой».

Настоящую книгу не следует рассматривать ни как самоучитель программирования, ни как сборник технических рецептов, ни как справочное пособие. Это именно учебник, посредством которого автор попытался донести до аудитории свое понимание специальности «Разработка бизнес-приложений на платформе 1С:Предприятие», а также поделиться некоторыми обобщениями практического опыта, накопленного за примерно четверть века профессиональной деятельности.

Ответ на второй вопрос — «Зачем?» — представляется очевидным. Зачем читают учебники? Чтобы изучить чужие идеи и опыт, ассимилировать изу­ченное, переработав его в своем сознании с учетом личных обстоятельств, и получить на выходе, во-первых, понимание нюансов профессии, которые до изучения материала представлялись нечеткими и, возможно, зыбкими, и, во-вторых, практическую пользу для своей производственной деятельности.

В чем упомянутая польза заключается? Для инженера, во всяком случае для компьютерного инженера, главной целевой функцией является эффективность (она же производительность труда, она же личная продуктивность, она же много чего еще). Соответственно, и настоящий учебник был изначально ориентирован на улучшение целевой функции, то есть на повышение эффективности. Разумеется, быть эффективным можно только в том случае, когда действие совершается без суеты и спешки, в правильном направлении и с полным пониманием происходящего.

Книга является развернутым ответом на вопрос, который периодически задают автору: «А как тебе удалось достичь такого профессионального уровня?» Краткий ответ дан в названии: «Не спеша, эффективно и правильно». А текст книги расшифровывает этот тезис. Как-то так…

---

¹ «Деринджер» — класс пистолетов простейшей конструкции, как правило, карманного размера. Название происходит от фамилии известного американского оружейника XIX века Генри Деринджера.

Глава 1. Выстраиваем концепцию

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

Мы, конечно же, не будем рассматривать все теоретические основы бизнеса. На нашей позиции нас более всего интересуют: 1) экономическая модель разработки, точнее, затратная часть этой модели; 2) модель работы на рынке труда ключевых участников процесса разработки, то есть специалиста и его работодателя; 3) те аспекты процесса разработки, которые в современном мире считаются новыми и перспективными (включая влияние на рынок труда). В соответствии с перечисленным выше мы и выстроили содержимое главы.

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

Краткий курс политэкономии

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

Наша конкретная область — это разработка бизнес-приложений, что, в свою очередь, является бизнесом. Когда мы говорим «бизнес», мы должны помнить про экономическую теорию (и, понятное дело, наоборот). Экономическая же теория гласит, что для максимально эффективного достижения поставленных целей в условиях ограниченности ресурсов выбор модели поведения в первую очередь обусловливается экономическими факторами. В переводе на русский это означает: «Начиная изучать какой-либо процесс, первым делом сформулируй хотя бы самую простую экономическую модель». Мы не претендуем на полноту формулировки модели, но некоторые ее важные детали постараемся показать, причем наглядно.

Два пути через торфяное болото разработки

Почти как в любом деле, в разработке программного обеспечения можно выделить два принципиально разных подхода (не только на платформе «1С:Предприятие», это универсальный принцип).

Путь 1. Быстро и криво

Простой подход — сделать быстро, затратив минимум ресурсов. Пускай будет слегка криво, пускай не будут учтены нюансы эксплуатации, пускай кое-где вылезут ошибки. Зато заработает прямо сразу (как мы всегда надеемся). Ну а потом исправим ошибки, напишем документацию, отработаем замечания заказчика и сделаем еще десяток добрых и полезных дел.

У такого подхода есть одно серьезное преимущество. Если расположение звезд окажется удачным, а разработчик более или менее опытным — что-то действительно заработает «прямо сразу». И какое-то время это «что-то» будет функционировать.

Но есть и недостатки, не менее серьезные. Во-первых, результат разработки по принципу «быстро и криво» далеко не всегда начинает работать «прямо сразу». Практика показывает, что частенько запуск проходит в строгом соответствии со старой шуткой о промышленном шпионаже: «после сборки тщательно обработать напильником».

Во-вторых, в процессе разработки нас ожидают типичные ловушки и, как результат, разработка практически со 100%-ной вероятностью имеет хотя бы один из перечисленных ниже изъянов.

• Неустойчивость к входным данным («Очень странно, у меня же все загружалось!»). При написании кода использовались самые примитивные примеры, а в реальных данных заказчика оказалась закопана добрая дюжина грабель с прочными дубовыми черенками.

• Несоответствие техническому заданию и ожиданиям заказчика в целом («Мы думали, что нужно просто создать и записать документы, а чтобы при повторной загрузке изменять ранее созданные вроде бы речи не было!»). Прямое следствие тактики «Код пишется параллельно чтению технического задания». Задание читается по диагонали, ведь писать код значительно интереснее.

• Неполнота реализации требуемых функций («Протоколирование мы пока еще не сделали, и в отчете пока только две колонки без детализации. Мы это потом доделаем, но данные загружать можно уже сейчас»). Заказчику предлагается что-то вроде легкового автомобиля без стекол и кресел — можно же пока и табуретку поставить. Используя инженерную смекалку, всегда можно найти временное решение. Беда (для заказчика) в том, что вре́менные решения с течением времени получают статус постоянных, раз уж проверку временем выдержали.

• Наличие элементарных ошибок. Под «элементарными» здесь понимаются такие ошибки, которые возникают в основном потоке событий приложения, причем с валидными входными данными («Здесь пока не обращайте внимания, просто нажмите Отмена, а дальше сначала нажмите Обновить, потом снимите и сразу поставьте обратно эту галочку, а потом уже Сформировать», — представитель заказчика лихорадочно записывает на бумажку). Работа с установкой «Мы просто пишем код», к сожалению, не предполагает затрат труда и времени на альфа-тестирование хотя бы основного потока событий и уж тем более альтернативных потоков.

• Низкое качество кода с точки зрения дальнейшего сопровождения и развития функциональности (через месяц после запуска: «Нет, эту функцию добавить не получится, тут нужно будет почти все полностью переписать». — «Почему?» — «Какие сроки были поставлены, вы помните? Поэтому и переписать!» Через шесть месяцев от представителя другой команды специалистов: «Кто же это вам такую красоту написал? Руки бы оторвать! Тут нужно все переделать с нуля!»).

Почему так?

«Ибо дело, свершенное в спешке, никогда не бывает свершено наилучшим образом» (Дэвид Эддингс, «Сияющая цитадель»²).

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

1) не менее 50 % трудозатрат — трудозатраты на отладку;

2) отсутствие внятных пользовательских инструкций;

3) большое (больше двух) количество итераций «сдали результат — попробовали эксплуатировать — что-то не работает — вернули на доработку»;

4) наличие ошибок, которые обнаруживаются вторым-третьим кликом;

5) наличие замечаний типа «Эта ошибка уже была в одной из предыдущих версий, но ее же исправляли?!»

Нельзя сказать, что подход «быстро и криво» является абсолютным злом. Существует несколько классов задач, где такой подход действительно позволяет значительно сэкономить трудовые и временны́е ресурсы.

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

• Ликвидация аварий. При тушении пожара хороши любые средства, и когда система собирается падать (или уже падает), вопросов, насколько грамотно, изящно и эффективно написан «подпирающий» код, не возникает в принципе. Только нужно потом не забыть заменить костыли добротной инженерной конструкцией (см. выше про «вре́менные решения»).

• Одноразовые инструменты «для себя». Когда требуется написать, например, какой-то крохотный корректировщик данных вида «использовал и выбросил», абсолютно незачем забивать себе голову «альтернативными потоками событий», «снижением издержек на сопровождение» или другими подобными высокими соображениями.

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

Путь 2. Не спеша, эффективно и правильно

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

1. Анализ. Изучение задачи, изучение текущего положения, выявление противоречий, уточнение неочевидных мест, допущений и ограничений.

2. Проектирование. Разработка «на бумаге». Принятие основных проектных решений (при необходимости с проверкой на быстром прототипе).

3. Кодирование. Собственно написание и отладка кода. Честно говоря, это не самое захватывающее занятие — если все продумано и правильно спроектировано, код является очевидным, и очень жаль, что сам себя он писать пока еще не способен.

4. Проверка. Прежде чем передавать какую-то разработку (даже на тести­рование), разработчик обязан самостоятельно проверить, по крайней мере, основной поток событий и поток наиболее очевидных ошибок.

5. Документирование. Написание инструкций по развертыванию, эксплуатации, разрешению известных проблем. Фиксация «на бумаге» наиболее важных и/или сложных проектных решений.

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

У разработки по принципу «не спеша, эффективно и правильно», разумеется, тоже имеются недостатки.

• От разработчика требуется не только мастерство в написании кода, но еще и способности к абстрактному мышлению.

• Также разработчику нужно понимать, что такое бизнес-анализ, и хотя бы мало-мальски уметь мысленно поставить себя на позицию пользователя. Никакой «работы по четкому ТЗ» здесь не будет, любое ТЗ придется потрошить в поисках противоречий и недосказанностей.

• Прямо завтра ничего не заработает. Как говорится, прежде чем поехать, какое-то время будем запрягать.

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

Преимущества же работы по принципу «не спеша, эффективно и правильно» в том, что это позволяет исключить практически все недостатки разработки «быстро и криво»:

• система устойчива к любым входным данным;

• результат соответствует ожиданиям заказчика;

• код содержит минимальное количество ошибок (если и встречаются, то некритические);

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

Смертельная схватка цены и качества

Казалось бы, вопрос только в цене, которую мы (и наш заказчик) готовы заплатить за качество. Достаточно выбрать метод реализации проекта: либо «быстро, криво, дешево», либо «медленно, качественно, дорого». В некоторых случаях упростить выбор заказчику может картинка-мотиватор (рис. 1.1).

Рис. 1.1. Памятка заказчику

Но, правда, есть нюансы.

Закон сохранения стоимости

Дело в том, что любая задача разработки по своей сути является чьей-то проблемой. На «создание проблемы» был затрачен определенный объем труда. Для полноценного решения задачи потребуется такой же объем труда и ни одним нормо-часом меньше.

Здесь работает брат-близнец закона сохранения массы имени Ломоносова и Лавуазье (хотя кто только этот закон не формулировал: в европейской истории среди первых был Эмпедокл, а в мировой — наверняка еще на стенах пещер царапали. Наиболее же остроумную трактовку фундаментального закона, относящуюся к соотношению числа компетентных и некомпетентных работников в компаниях, предложил Скотт Адамс в своей замечательной книге «Принцип Дилберта»³).

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

То, что результат неполный, можно определить по самым разным признакам. Например:  

• действия, которые могли быть автоматизированы при полноценной разработке, автоматизированы не все. Следствие — пользователи затрачивают лишнее время на ручные операции;

• не реализована проверка входных данных, нет защиты от неправильных действий пользователей. Следствие — множественные ошибки ввода;

• отсутствуют средства протоколирования. Следствие — невозможно разобраться в причинах некорректного поведения системы («Это пользователь ввел что-то не так или система посчитала неправильно? А может, звезды не так стояли?»); для групповых операций невозможно «откатить обратно» или «запустить заново с места сбоя»;

• добавление новой функции и/или модернизация любой существующей требует затрат, сопоставимых с исходной разработкой;

• большое число ошибок в коде приводит к частым сбоям и простоям (а это тоже затраты заказчика, пускай и косвенные) —

и так далее.

В общем, если на стадии разработки был применен принцип «быстро и криво», то на стадии эксплуатации это закономерно приведет к паттерну «криво, медленно и печально».

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

Парадокс убыточного удешевления

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

Разработка по принципу «быстро и криво» не может обойтись дешевле, чем разработка по принципу «не спеша, эффективно и правильно». А если проект будет реализован криво, то такая разработка может обойтись и значительно дороже.

Это важный момент, и мы разберем его подробно на реальном примере из практики автора. Без имен и названий, разумеется (хотя действующие лица, если текст попадется им в руки, без сомнения, себя узнают). Масштаб немного изменен для наглядности, но в первую очередь еще и потому, что NDA⁴ нужно уважать.

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

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

Концептуальная часть инженерного решения была вполне грамотной. Если нужно свести данные из пяти разнородных систем в одну, представлялось разумным разработать некий промежуточный формат, перегонять локальные данные в унифицированные файлы, а затем уже загружать в единую систему. Прекрасное было решение, без шуток. Но техническое воплощение этой концепции в личном рейтинге автора в номинации «Быстро и криво» и по сию пору занимает безоговорочное первое место. Объясню почему.

Во-первых, в качестве формата для промежуточных данных был выбран MS Excel строго определенной версии — формат, не обеспечивавший даже элементарного «прочитано будет точно то же значение, что и было записано». Очень сложно объяснить ответственным за инфраструктуру, что на серверах нужно установить MS Office такой-то, чтобы можно было вызывать Excel через COM-соединение, притом что ранее была поставлена задача перевести часть серверного парка на Linux.

Почему же был выбран самый неудобный формат? Почему не JSON, не XML, даже не xBase? Подрядчик, разумеется, настоящую причину не озвучил. А дело было в том, что у «программиста» имелись некие готовые механизмы работы с файлами Excel. И чтобы не писать код заново (а еще, не дай бог, не тратить время на изучение приемов работы с JSON/XML), проще эксгумировать старый код и как-нибудь натянуть его на задачу. Экономия трудозатрат? Ударная скорость разработки? Вне всякого сомнения!

Во-вторых, было принято техническое решение класса epic — не изобретать новые механизмы загрузки данных, а слегка допилить уже встроенную в типовое решение механику перехода с предыдущей редакции (здесь следует передать горячий привет «правилам конвертации», и мы не упустим такого случая: «Привет, правила! Идущий К Ручью С Камнем На Шее приветствует вас!»). Да, при таком решении весь программный код работы с данными (начиная с чтения *.xlsx) придется утрамбовать в некий «дополнительный обработчик», то есть в обычный текстовый файл. Да, этот код будет исполняться через оператор Выполнить и его невозможно будет даже пройти отладчиком. Ну и что, отладка — для тру́сов! А нашим крутым «программистам» достаточно лишь пристального взгляда, чтобы найти все ошибки, даже в спагетти-коде в полторы тысячи строк.

И в-третьих, на стороне подрядчика никому не пришло в голову, что промышленная загрузка сотен и сотен файлов в единую систему «немножечко» отличается от загрузки единичного файла в настольную, по сути, информационную базу. Ведь нет гарантии, что локальные данные чужеродной системы с первого раза совпадут с парадигмой целевой конфигурации и их не придется загружать повторно. Также не подумали, что число ручных операций и процедур клиент-серверного взаимодействия нужно минимизировать. Не реализовали «страшную» процедуру верификации входных данных и пошли по сценарию «начали загружать, обнаружили ошибку в данных, запаниковали, бросили работу».

Казалось бы, лучшие практики не представляют собой секрета. В самом простом варианте:

• загрузчик на стороне кластера слушает некую директорию;

• файлы для загрузки подкладываются туда по мере поступления;

• каждый файл содержит аннотацию (что это, откуда, куда загрузить, кого уведомить);

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

Да, такой загрузчик еще нужно написать и отладить. Но зачем? Все уже было написано. Быстрая разработка предполагает, что есть готовый код — его нужно использовать по максимуму.

И пусть специалисты, занятые на процессах миграции данных, вручную запускают клиентское приложение: «Начальная загрузка, три страницы мастера (настройки всегда одинаковы), выбрать файл и ждать, когда и чем закончится». Сколько ждать — десять минут, час или пять? — никакого намека на «обработано примерно N %». А что будет, если десять биороботов запустят по 7–8 потоков загрузки каждый, причем в рабочее время и одновременно? На инфраструктуру ляжет нагрузка 80 сеансов, каждый из которых пишет и проводит сотни (а то и тысячи) документов без всяких пауз, вкупе с обычной нагрузкой от пользователей единой системы. Но выдержит ли? Можно даже делать ставки (только, понятное дело, админов к тотализатору не допускать!).

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

Вот теперь давайте посчитаем трудозатраты на разработку и проверку самого простого пакетного загрузчика —хотя бы в первом приближении, по принципу «на два лаптя правее солнышка». Пусть будет десять рабочих дней (80 часов). Допустим, весь проект рассчитан на год, и техник, который будет вести и контролировать процесс, потребуется примерно на два часа в день. На 2023 год (где 247 рабочих дней) получается: 80 + 247 × 2 = 574 часа.

Фронт работ в полях: примерно тысяча локальных систем. Надо учитывать, что редко какая миграция удается с первого раза, и не только по техническим причинам (напоминаю, в нашем примере имел место «саботаж на местах»). Допустим, что показатель «число загрузок на систему» составляет 2,5 раза (хотя, по правде, число занижено). Предположим, что время, требуемое технику на одну операцию загрузки без учета нештатных ситуаций, — 30 минут. Примем, что разработка инфраструктурного слоя для загрузчика данных не была реализована — 0 часов. Считаем: 0 + 1000 × 2,5 × 30/60 = ~1250 часов. И это самая нижняя планка.

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

Теперь представим, что показатель «число загрузок на одну локальную систему» составит хотя бы 3,5 раза (например, сложная предметная область, множественные ошибки и недоработки в инструментах конвертации, массовое саботирование процесса выверки данных, необоснованные требования повторной миграции и так далее). И представим, что средняя операция загрузки потребует не 30, а 45 минут рабочего времени техника (учтем ситуации, когда «загрузка упала, нужно заново»). Получается 1000 × 3,5 × 45/60 = 2625 часов.

А если предстоит миграция 1000 локальных систем только в первой очереди проекта, еще 700 во второй очереди и еще 500 в третьей? Придется как минимум еще разок удвоить стоимость.

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

Парадокс психологии руководителя

Тем, кто работает в отрасли достаточно долго, из практики известно, что при прочих равных руководители всех уровней из вариантов: 1) «быстро и криво» и 2) «не спеша, эффективно и правильно» — почти всегда выбирают первый. Почему?

Все просто. Здесь срабатывают сразу две ментальные ловушки: «выгодная цена» и «все будет хорошо».

Ловушка выгодной цены прекрасно известна всякому, кто хотя бы раз в месяц бывает в супермаркетах. Именно там попавшие в ловушку граждане-экономы покупают годовой запас самой дрянной туалетной бумаги за крайне выгодную цену 19 рублей. Хотя четырехслойную бумагу с ароматом ромашки за 119 руб­лей им пришлось бы покупать куда реже, затраты на год остались бы на том же уровне, а уровень личного комфорта получился бы на два порядка выше.

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

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

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

Если отжать из болтовни сухой остаток, получится примерно такая формулировка.

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

Читатель без труда может провести простейший тест на профпригодность руководителя любого звена, от тимлида до директора. Нужно всего лишь ненавязчиво поинтересоваться отношением товарища руководителя к работе граждан Тома Демарко и Тимоти Листера, изданной под названием «Вальсируя с