О книге

Книга Никиты Зайцева (в профессиональном сообществе более известного как WildHare) — пример того, как можно систематизировать и упаковать в текстовый формат профессиональный опыт, накопленный за почти 25 лет успешной инженерной практики и участия в больших и по-хорошему «страшных» инженерных проектах.

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

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

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

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

Желаем приятного и полезного чтения!

Об авторе

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

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

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

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

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

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и так далее.

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

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

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

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

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

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

Место действия — масштабный амбициозный проект по разработке и запуску большой и по-хорошему «страшной» информационной системы. Один из этапов проекта — перенос (миграция) почти тысячи локальных систем со всеми данными «с земли» в единый облачный программный комплекс. «Наземные» системы относились к нескольким разным типам, из которых только одна была реализована на платформе 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 первый знак слева.

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

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

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

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

Читатель без труда может провести простейший тест на профпригодность руководителя любого звена, от тимлида до директора. Нужно всего лишь ненавязчиво поинтересоваться отношением товарища руководителя к работе граждан Тома Демарко и Тимоти Листера, изданной под названием «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения»5. Если ответом будет изумленное «Что?» поверх стопки покетбуков из серии «Очередной учебник менеджмента, или Как повысить продуктивность и креативность работы в команде через геймификацию, хакатоны и гибкие методики», диагноз можно поставить мгновенно. Неутешительный, надо признать, диагноз.

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

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

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

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

• продумать план разговора;

• заготовить досье;

• создать точный перечень проблем и потерь — какие и когда были;

• провести расчеты;

• сформулировать аргументы.

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

Парадоксы эффективной разработки

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

Приведем аналогию из мира прекрасного, например шахматы. Дилетант знает, как ходят фигуры, знает некоторые правила, возможно, даже знает, как и для чего пользоваться шахматными часами. Но играет по наитию — как мироздание на душу положит: «Если достались белые, сходим e2 — e4, ввяжемся в бой, а там посмотрим». Профессиональный же игрок не просто знает физический смысл понятия «гамбит», но, к примеру, может внятно объяснить тактический прием под названием «гамбит Геринга» и применить его при разыгрывании шотландской партии. А это, уж поверьте, будет непросто.

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

Так в чем же парадоксы? Формула вроде бы очень простая: «“долго, дорого, занудно” равняется “качественно, надежно, удобно”».

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

У коллеги база расположена вот здесь:

c:\Работа\Базы\хрень-9

У автора хранение организовано иначе:

c:\home\v8-stuff\infobases\dev\sm\jt-3741\storage-common

что означает: «домашний каталог\материалы по восьмой платформе\информационные базы\разработка\задача описана в JIRA под номером 3741\общее хранилище». Это занудство или эффективность? Попробуйте угадать.

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

И наконец, самое парадоксальное. Эффективная разработка требует от специалиста аккуратности, развитого абстрактного мышления, высокой квалификации, знания множества отраслевых паттернов, умения изобретать инженерные решения и так далее. Но на практике занудная эффективная разработка поглощает существенно меньший объем труда и времени, чем быстрая и веселая. При этом эффективный специалист зарабатывает существенно больше денег, чем его быстрые коллеги. Вы не поверите, но иногда даже кратно больше (автору такие феномены известны).

Домашнее задание читателю. Грамотно с точки зрения предпочтений присвойте количественные характеристики «меньше» и «больше»: а) затратам рабочего времени; б) денежным знакам, имеющим хождение в стране проживания читателя.

Кофе-пауза #1. Орден Бани для ИТ

Сперва в качестве эпиграфа повторим слова замечательного американского писателя-фантаста в жанре фэнтези Дэвида Эддингса:

«Ибо дело, свершенное в спешке, никогда не бывает свершено наилучшим образом».

А теперь давайте придумаем рыцарский орден для тех специалистов по ИТ, которые выполняют свою работу с торопливостью, достойной человека, который в бане голышом изо всех сил спешит в парилку. Так и назовем: Почетнейший орден Бани для ИТ (The Most Honourable Order of the Bath for IT). Надеюсь, Георг I6 простит автору этот легкий плагиат.

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

У ордена две степени: «Легкое поведение в сауне» и «Реальная паровая баня». Посвящение кандидатов проводится строго по канону короля Георга:

• ночное бдение (над важной и срочной задачей);

• молитва («Господь всемогущий, пожалуйста, сделай так, чтобы эта хрень запустилась»);

• аскеза (никаких печенек до утра, и сахар закончился);

• макание лицом в ледяную воду в финале (осознание разрушительных последствий своей деятельности — руководители и старшие товарищи помогут).

Примеры? Сколько угодно. Вот на выбор три кавалера (все истории, разумеется, подлинные, ничего не выдумано).

Мистер Синий. Служил техником на очень большом проекте. Очень торопился завершить рутинную, скучную, но крайне важную задачу. Работа велась через RDP-сессию, и с последним выдохом «Ну наконец-то!» гражданин последовательно нажал на «Пуск» и на «Завершить работу». Поздний вечер пятницы, все админы давно в кабаке, номера их телефонов — коммерческая тайна заказчика. Коллегам, которые на этом же сервере решали свои не менее важные задачи или предполагали заняться ими в субботу, было крайне весело. Орден Бани для ИТ II степени.

Мистер Розовый. Служил в коммерческой конторе на должности DBA в те «лохматые» годы, когда в ходу был еще MS SQL Server 6.5, занимался мелкой подстройкой параметров производительности. Где-то вычитал, что можно поместить часть tempdb прямо в RAM, и так загорелся этой идеей, что в спешке не разобрался в метрике. Задал емкость в Kb, а надо было в Mb. После перезапуска от СУБД осталось одно только сообщение об ошибке. В техническом английском гражданин был не силен, так что ему показалось, что сервер сказал что-то вроде «Ха-ха, тупое ты <много слов 18+>!»). Результат: деятельность предприятия парализована на целый рабочий день, при лихорадочной попытке переустановки испорчена база данных, крайний бэкап был двое суток назад. И всего-то пять поспешных тюков по клавиатуре! Орден Бани для ИТ I степени.

Мистер Зеленоватый. Служил директором по ИТ на большом заводе. Должность громкая, но, по сути, просто совмещал обязанности главного админа и главного программиста. Очень торопился завершить переезд инфраструктуры на новое железо, даже остался в серверной на ночь. Чтобы не потерять аппаратный ключ (запасного нет), положил в самое надежное место, в карман брюк. А рано утром сел в поезд и уехал в отпуск в какую-то тмутаракань. Разумеется, с аппаратным ключом в кармане. Как вы думаете, насколько просто достать ключ на 500 лицензий хмурым утром вторника, будучи рядовым админом на глухом провинциальном заводе, откуда до ближайшего дистрибьютора пилить две сотни верст? Полный кавалер ордена Бани для ИТ. Ордена предписано носить на тех самых брюках, но не на кармане.

Читатель скажет: «Админы такие админы, но при чем здесь разработка?» Нет повода волноваться, уважаемый читатель, дойдет очередь и до разработчиков.

Собеседование в трех гримасах

Почему-то на собеседовании принято задавать множество различных и зачастую глупых вопросов. Топ-3 HR-беспомощности, по версии автора, выглядит следующим образом:

1. «Почему мы должны нанять именно вас?»;

2. «Кем вы себя видите в нашей компании через пять лет?»;

3. «Какими задачами вам интересно было бы заниматься?».

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

Вопрос 1. Ремесло или творчество?

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

Никакие мы не программисты. Мы разработчики прикладного программного обеспечения.

Ну а кто же тогда настоящий программист? Ну, например, парень, который развлечения ради может взять голое железо и написать на Асме Форт, а на Форте Лисп — за субботний вечер «под бутылочку доброго “Сингл Молт”» и теплый ламповый джаз. Автор в свое время был знаком с несколькими такими парнями. Да, они могут писать и на 1Cv8, но это не превращает их в «1С-программистов».

Не поленимся почтить формальную логику и запишем очередную гранитную формулировку.

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

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

Никакого творчества в разработке программного обеспечения нет, и взяться там ему неоткуда.

Разработка — это безусловное ремесло.

Суть процесса разработки заключается в том, чтобы:

1) распознать задачу и декомпозировать до необходимого уровня;

2) выбрать из набора уже известных паттернов нужные и временно забыть про все остальные;

3) недостающие паттерны найти, изучить и включить в свою ментальную биб­лиотеку;

4) несуществующие, но необходимые паттерны изобрести, запомнить и поделиться с коллегами;

5) разработать необходимое программное обеспечение, применяя правильные паттерны к отдельным компонентам задачи.

«Изобрести», а не «сотворить», понимаете?! Хайрем Максим7 и Дуглас Энгельбарт8 (эрудированный читатель может подставить имена своих любимых инженеров) не были творческими людьми, они не творили, а изобретали и конструировали. Даже великий Леонардо, когда от мольберта переходил на тогдашний аналог кульмана, временно переставал быть человеком творческой профессии.

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

«Вы человек творческой профессии? Спасибо, мы вам обязательно позвоним».

Вопрос 2. Олимпиада или производство?

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

Олимпийский (назовем его так) стиль разработки предполагает, что целью является решение конкретной задачи, и только ее. И решение должно быть рекордным — самым быстрым, изящным, остроумным, компактным, самым <подставьте любое слово>. Ни о каком сопровождении и развитии речи даже близко нет. Поэтому обычный линейный специалист не сможет понять, почему код, написанный олимпийским небожителем, вообще работает. В таком коде страшно тронуть даже комментарий (а он может состоять из одного слова — три буквы, средняя «у», не «душ»).

Почему же для эффективной разработки олимпийский стиль есть безусловное зло и беда (а это именно так)? Попробуем призвать на помощь добрую фею из мира прекрасного — Аналогию. Три кейса из военной истории на выбор.

1. Беспосадочный перелет экипажа АНТ-25 из Москвы до Ванкувера через Северный полюс под командованием Валерия Чкалова. Тысяча девятьсот тридцать седьмой год. Авиация Красной армии наглядно показала американским коллегам, что сможет отправлять бомбардировщики в любую точку на карте мира.

2. Рейд американских базовых бомбардировщиков B-25B на Токио под командованием подполковника Джеймса Дуллитла. Тысяча девятьсот сорок второй год. Задействовав авианосец «Хорнет», американская армия наглядно показала японским «коллегам», что, даже лишившись всех баз в Тихом океане, можно достать до Токио.

3. Переход американского низкобортного башенного броненосца «Миантаномо» через Атлантический океан в Европу (миссию возглавлял военно-морской министр США Густав Ваза Фокс). Тысяча восемьсот шестьдесят шестой год. Американский флот наглядно показал «коллегам» из Англии и Франции, что за рекордные 11 дней сможет подогнать пару-тройку своих монстров прямо в гавань Плимута.

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

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

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

• Целью было — повысить моральный дух собственных войск и оказать моральное давление на противника.

• Никакой практической пользы от выполнения рекордных задач не последовало.

• Попыток повторения задачи именно в таком виде больше не предпринималось, каждая из представленных задач была решена в единственном экземпляре.

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

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

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

«Забудь все, чему тебя учили раньше. Здесь ты будешь учиться работать».

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

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

«Мы работаем за деньги, решаем технические проблемы заказчика и со­здаем для него материальные блага».

Давайте попробуем перечислить родовые признаки эффективной разработки в производстве.

1. Целью производственной деятельности не является решение каких-либо задач только ради их решения:

• основой целью в коммерческом производстве является создание добавленной стоимости через изготовление продукции и/или оказание услуг;

• в некоммерческом производстве (если такое вообще бывает) цель описана в соответствующем положении устава.

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

3. При разработке программного продукта уже на этапе эскизного проектирования сразу принимается во внимание фактор эксплуатации:

• возможность сопровождения даже специалистами не очень высокой квалификации;

• необходимость устойчивости к изменениям в окружении (в самом широком смысле слова «окружение»);

• снижение лишних расходов, где только возможно.

Иными словами, при производственном подходе разработчик задается не только вопросом «как это запилить поизящнее?», а еще и «насколько дешево, просто и удобно возможно будет это сопровождать, расширять и развивать?».

Фабричный гудок, разумеется, звучит не так ярко и бодро, как «We are the champions»9 (и автор позволит себе мелкую пакость, указав, что эту песню по канону поют до выхода на бой и уж никак не после победы). Но дела на фабрике идут, контора пишет, касса выдает деньги — день за днем, месяц за месяцем. Олимпийское же золото абсолютному большинству чемпионов доведется увидеть либо в сладком сне, либо на груди более успешного противника.

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

Техническое задание или технический проект?

У этого вопроса даже не двойное, а тройное дно. Первый смысловой слой: а в чем, собственно, разница, если она вообще имеется? Для граждан, исповедующих религию «просто пиши код», разницы, разумеется, никакой нет (будь автор сородичем ехидны, то непременно заметил бы, что в руках «просто пишущего код» любой язык программирования со временем неизбежно превращается не только в Brainfuck, но и в Oook! Но автор — человек вежливый и ехидных замечаний, конечно же, себе не позволяет).

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

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

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

Эффективная разработка не допускает существования «технических заданий» и четко разграничивает компетенции:

• сбора требований;

• системного анализа;

• технического проектирования.

Действуем по аналогии с «Игрой престолов»: первым делом строим Великую Стену. За Стеной — одичалые (заказчики со своими «дикими» требованиями), там действуют наши отважные разведчики из департамента бизнес-анализа. По южную сторону Стены стоят наши рабочие станции, клацают кнопки, запиливается и тестируется программный код. Для полноты образа не хватает разве что лорда-командующего — в Черном замке (кабинете), на самой границе света (опенспейс) и мрака (рыночная конкуренция).

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

Разрабатывать без технического задания вполне можно. Без технического проекта — нельзя.

«А вы, юноша, “умеете в техническое проектирование”? Поясните, пожалуйста, в чем разница между activity diagram и sequence diagram. А что так? Не любите UML?10 Все верно, незачем — рисуешь кривые картинки, как Пикассо, а их потом никто и не смотрит. Спасибо, мы обязательно вам позвоним (если звонилку найдем, конечно)».

Кофе-пауза #2. Если бы мы строили дома…

Как говаривал любимый философ автора мсье Монтень11, добродетель, перейдя границы разумного, оборачивается пороком. Этот принцип является универсальным и может быть использован абсолютно в любой деятельности Homo sapiens. Попробуем определить границы разумного на примерах строительного ремесла. Отчего-то наша добрая фея из мира прекрасного Аналогия считает, что строительные проекты похожи на проекты разработки программных продуктов.

Как и любой серьезный разговор за чашкой кофе, начать следует с пары замшелых шуток. Для таких случаев у автора есть старая добрая шутка про точное соблюдение технических заданий. Строительная площадка, дело идет к приемке, репетируют сдачу объекта. В роли представителя заказчика выступает опытный инженер-строитель из дружественного треста. Подрядчик демонстрирует удивительное сооружение: на прибрежном холме выкопана круглая 30-метровая шахта, внутри выложенная железобетоном, на дне — очень мощный прожектор.

— Э… Юноша, что вы мне такое показываете?

— Сам не очень понимаю, но все сделано точно по ТЗ, вот чертежи.

— Э… (переворачивает чертежи), а вам не кажется, что они заказывали маяк?

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

Первый объект строительства — крупный деловой центр, оформленный в стиле «космический модерн». Что-то вроде звездолета USSEnterprise NСС-1701-D. Одной из фишек были скоростные лифты в металлических шахтах-колоннах. После монтажа лифтовое оборудование следовало проверить, так что выполнили пробный пуск — сразу с первого этажа до верхнего. Лифт в такой шахте действует почти так же, как поршень велосипедного насоса, а проектировщик просто-напросто не предусмотрел отвод воздуха из этих своих космических сооружений. Так в соревновании пневматики с прочностью металла победила стихия воздуха, все лифтовые двери оказались выбиты и разломаны. К счастью, никто не погиб и не пострадал.

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

• Владельцы квартир класса люкс и джакузи покупают люксовые — большие и очень тяжелые.

• Дом спроектирован так, что все места под джакузи расположены строго одно под другим.

• В отличие от ванн, которыми жильцы пользуются редко, а потому не одновременно, в джакузи все залезают примерно в одно время.

• В джакузи, как ни странно, наливается вода, и, что еще страннее, эта вода имеет ненулевой вес.

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

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

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

В одном старом-престаром баяне говорится: «Какое же счастье, что программисты не строят дома! Иначе первый же случайно залетевший “дятел” разрушил бы всю нашу вековую цивилизацию».

Три простых способа все испортить

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

Способ 1. Как превратить работу в детский утренник

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

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

В нашей с вами отрасли обычно практикуют «геймификацию курильщика». Происходит это примерно так... Вот наш флагманский продукт, который мы запиливаем. Вот наши разработчики: Петя, Митя, Миша и Маша. Вот наш баг-трекер, в котором записаны сотни ошибок. А вот наша HR-затейница ЖЭ (Жозефина Эдуардовна, а не то, что подумал читатель), которая читала модные книжки и даже ходила на специальные курсы. ЖЭ вешает на стену красивую большую бумажку с фотографиями разработчиков. Каждую неделю ведется подсчет, кто сколько ошибок исправил. Лидер получает: а) звездочку на бумажку; б) маленький тортик со свечкой; в) хоровое исполнение «Сколько багов ты исправил и какой ты, Миша, молодец!» на мотив «Happy Birthday» при участии всего опенспейса. Можно даже вприсядку, с прихлопом.

Если звездочка вторая подряд, она золотая, если третья — рубиновая. Четыре подряд дают приз в формате плюшевой симпатяшки. Каждый месяц результаты обнуляются, но победителю месяца выдают почетную грамоту и флажок на рабочий стол. Лепят звездочку уже на другую бумажку, где идет соревнование за годовой трофей. Большая (реально большая) плю­шевая симпатяшка, корзина (действительно корзина) конфет и пара билетов на шоу модного исполнителя. Ну а если разработчиков не четыре, а двести сорок четыре, можно закрутить такие сценарии, что придется написать книгу правил.

Бывает ли что-нибудь тупее? Затейница ЖЭ возразит, что ей поручили мотивировать разработчиков на исправление ошибок, а то им неинтересно. Само собой, кому интересно ковыряться в чужих копролитах? Скажите, разве суммы в платежных ведомостях никак не мотивируют наших милых молодых людей и для выполнения рабочих задач перед ними нужно водить хороводы? Вместо того чтобы решать задачу «снизить количество ошибок и усилить контроль качества», компания (за свой, заметим, счет) зачем-то решает задачу «потеребить у разработчиков железу́ детской радости, авось они будут стараться чуточку сильнее».

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

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

Вопрос: если адмирал не может доверять своим капитанам даже в такой мелочи, как 15 копеек за принятую тонну топлива, то как можно доверять им в бою? Аналитики сходятся в том, что план боя: «Держать генеральный курс — 23°, в случае выбытия флагмана колонну ведет следующий мателот» — был разработан Рожественским в таком виде (а это весь план сражения, почти дословно) не потому, что Зиновий Петрович был клинически туп, а потому, что адмирал абсолютно не доверял командирам кораблей.

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

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

Хотя, казалось бы, надо нанять чуть больше людей, учредить обязательный аудит кода (пары «кодер/аудитор» меняются каждую итерацию) и объявить команде: «Если за квартал количество актуальных ошибок будет снижено до N, но без ущерба для плана выпуска, команда получит квартальную премию в размере M % квартального ФОТ». При этом звездочки тоже можно лепить, только не золотые, а коричневые. Каждый отказ вида «отдал исправление на проверку — вернули на доработку» добавляет балл. У кого больше баллов за неделю — звездочка.

Вот это будет геймификация взрослого здорового человека. И результат, что характерно, ждать себя не заставит.

Способ 2. Как превратить работу в штурм крепости

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

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

Такой стиль работы, кстати, активно практикуется на Корейском полуострове. И не для свершения каких-то трудовых подвигов, а в обычной, повседневной деятельности. На Севере это называется «сокточжон» (по-русски «скоростной бой»), на Юге ровно тот же подход именуется «палли-палли» (что-то типа нашего «давай-давай»). Если читатель по примеру автора будет иногда читать северокорейские новости (доступны на русском), то заголовок «Сегодня товарищ Ким Чен Ын на заводе по производству крепкого алкоголя ведет скоростной бой за качество» не будет ошибкой переводчика. А соль этой шутки в том, что «скоростной бой» ведется за качество. Какое качество получается, когда исполнитель видит в задаче врага, которого необходимо уничтожить как можно скорее, работая в темпе даже не вальса, а урагана?

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

Можно ли решить сложную инженерную задачу методом коллективного штурма? Всякий опытный инженер после получения вводной скажет что-нибудь такое: «Требования вроде понятны, теперь с этой задачей нужно переспать, продолжим завтра». Скоростное написание кода само по себе не имеет никакого смысла, смысл имеют проектные решения. Проектные решения, принятые в спешке, без анализа, критики и защиты, почти всегда оказываются плохими. Но когда код уже запилен, его уже не выбросить — будем делать продукт. Это ничего, что множество важных второстепенных функций не продуманы и придется их потом запиливать по живому. MVP12 у нас уже родился, а рисовать модельки — для дураков. Пусть и багов в нашем MVP как тараканов в кухмистерской образца XIX века, со временем поправим. Уже можно продавать.

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

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

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

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

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

Способ 3. Как согнуть работу в бараний рог

Разумеется, слово «гнуть» в заголовке поставлено не случайно. Речь пойдет о модных «гибких методиках разработки». Автор дает честное слово, что не хочет сказать ничего плохого про семейство технологий Agile13. Наоборот, автор сам использует или пытается использовать какие-то их элементы в своей производственной деятельности. Речь пойдет о том, что у каждой методики есть теоретическая база и практическая применимость к решению тех или иных задач разработки (сон разума «Agile-управление Министерством путей сообщения» мы рассматривать не будем).

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

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

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

Или вот еще такой «замечательный» совет дают руководителям, начинающим осваивать гибкость: не фиксировать жестко длительность итерации. Скажем, по уставу команды это две недели, но если руководитель очень занят и не получается выделить несколько часов на ретроспективу, то перезапуск итерации можно и подвинуть. Тогда какой смысл был планировать задачи на две недели, если сопоставление плана с фактом производится через пять? Бо́льшая часть задач, которыми занималась команда, изначально не входила в план итерации, а была поставлена на ходу. Что и как мы сможем оценить в ретроспективе, какие сможем сделать выводы? Никаких, кроме «ну, вроде мы молодцы, что тратим время с пользой».

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

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

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

Можно привести великое множество примеров сгибания рабочего процесса до состояния бараньего рога (по мнению автора, искажать методику Agile-управления с точностью до наоборот означает добровольно признать некоторую степень родства с этим благородным животным).

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

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

Все же для начала надо перестать считать «гибкие методики» чем-то новым. Неужели кто-то думает, что если «планерку» перевести как stand-up, «разбор полетов» назвать «ретроспективой», от «демонстрации» оставить огрызок и написать его транслитом demo, месячный план набегающей волной разбить на две «итерации» и так далее, — от этой словесной чехарды старая советская инженерная и управленческая методика заиграет новыми красками?

Хотя кто знает? Тогда давайте назовем старую добрую вечернюю прогулку «позитивной аэробной кардионагрузкой», это должно произвести неизгладимое впечатление на артериальную гипертензию.

Кофе-пауза #3. Байки из нейросклепа

Эту историю автор вспоминает всякий раз, когда коллеги в кофе-румах заводят жаркие разговоры о феноменальном развитии новомодных технологий «big data», «deep machine learning», «blockchain», «беспилотность» ну и сверкают разными другими гранями владения вопросом о сортах расцветающих на Марсе яблонь.

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

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

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

И вот Миша как-то воспроизвел в лицах свой разговор с бывшим то ли одноклассником, то ли однокурсником, назовем его условно Петром. Петр позволил своему мозгу «утечь» из страны и уехал работать на дядюшку Билла, в Редмонд14.

— Ну и чем ты сейчас занят в MS? Интересные наверняка задачи.

— Да фигню какую-то пишу на Java. Даже не знаю, в какой проект. Так, взять отсюда датасет, перевернуть и положить вот сюда. А у тебя что?

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

— Это что, в НИИ каком-то?

— Не, «Алкогольная компания».

— Какая-какая компания?!

— Ал-ко-голь-на-я. Ну, водкой торгуем, оптовая база.

— … (стук падающей на пол челюсти).

Распознавалку, что характерно, довели до вполне промышленного релиза, оформили как внешнюю компоненту для тогда еще версии 7.7 (на сетевых просторах наверняка где-то можно найти, OCR Pelican). Но до внедрения дело не дошло. Почему? Во-первых, точность все-таки была не 100%-ная. Во-вторых, требовался промышленный потоковый сканер, а его стоимость была сопоставима с ФОТ (фонд оплаты труда) всех занятых на ручном вводе операторов на несколько лет вперед. Скажем так: идея опередила свое время.

К слову, «решить задачу машинного зрения» некий профессор в MIT15 ставил выпускникам на летнюю практику еще до рождения автора этих строк, в самую первую AI-лихорадку. Да, такие идеи появляются регулярно и мутируют со скоростью коронавируса.

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

Интересно, а понимают ли, например, бухгалтеры, что их не заменяют роботами только потому, что сшить уголовное дело можно только на человека? И понимают ли коллеги из кофе-рума, что беспилотные автомобильчики — это просто еще один шаг к беспилотным средствам разработки программных продуктов?

Если подумать, то Скайнет16 не такая уж завиральная фантастика.

---