Disclaimer
Коллеги, вашему вниманию предлагается почти финальный вариант моей книжки. Была и остается идея издать это в бумажном варианте, но идея довольно зыбкая. К сожалению, имеются некоторые проблемы со здоровьем. Но очень хочется, чтобы труд не пропал, поэтому книжка отдается в открытый доступ. Можно публиковать где угодно, цитировать и так далее. Единственное условие — ничего в тексте не менять и указывать авторство. Автор текста — Никита Викторович Зайцев (также известный как WildHare).
Книжка повествует об эффективной разработке программного обеспечения. Можно сказать, что это дистиллят моей личной практики, наработанного опыта, знаний и умений.
Предыстория появления книжки в формате интервью порталу Инфостарт:
//infostart.ru/journal/news/mir-1s/nikita-zaytsev-ya-universalnyy-soldat-v-mire-1s_1250753/
Это уже не полуфабрикат, а почти готовый продукт, правда без нескольких не особо важных деталей. Если работу над книжкой получится продолжить, то эти недостающие детали будут добавляться именно сюда, в эти файлы.
Приятного чтения ;-)
Краткий курс политэкономии
Два пути через торфяное болото разработки
Как и почти в любом деле, в разработке программного обеспечения (и не только на платформе “1С:Предприятие”, это универсальный принцип) можно выделить два принципиально разных подхода.
Быстро и криво
Простой подход — сделать быстро, затратив минимум ресурсов. Пускай будет слегка криво, пускай не будут учтены нюансы эксплуатации, пускай кое-где вылезают ошибки. Зато заработает (как мы всегда надеемся) прямо сразу. Ну а потом исправим ошибки, напишем документацию, отработаем замечания заказчика, и сделаем еще десяток добрых и полезных дел.
У такого подхода есть одно серьезное преимущество. Если расположение звезд окажется удачным, а разработчик более-менее опытным — действительно, что-то заработает прямо сразу. И какое-то время это “что-то” будет функционировать.
Но есть и три не менее серьезных недостатка. Во-первых, результат разработки в стиле “быстро и криво” далеко не всегда начинает работать прямо сразу. Практика показывает, что запуск частенько проходит в строгом соответствии со старой шуткой о промышленном шпионаже, где “после сборки тщательно обработать напильником”.
Во-вторых, результат разработки с вероятностью практически 100% попадает хотя бы в одну из типичных ловушек:
- Неустойчивость к входным данным (“Очень странно, у меня же все загружалось”). При написании кода использовались самые примитивные примеры, а в реальных данных заказчика оказалась закопана добрая дюжина грабель с прочными дубовыми черенками.
- Несоответствие техническому заданию и ожиданиям заказчика в целом. (“Но мы думали, что здесь нужно просто создать и записать документы, а чтобы при повторной загрузке изменять ранее созданные речи вроде бы не было”). Прямое следствие методики “код пишется параллельно чтению технического задания”. Задание читается по диагонали, писать код значительно интереснее.
- Неполнота реализации требуемых функций. (“Протоколирование мы пока еще не сделали, и в отчете пока только две колонки без детализации. Это мы потом доделаем, но данные загружать можно уже сейчас”). Заказчику предлагается что-то вроде легкового автомобиля без стекол и кресел, но можно же пока табуретку поставить? Используя инженерную смекалку, всегда можно найти временное решение. Беда (для заказчика) в том, что временные решения с течением времени получают статус постоянных, раз уж выдержали проверку временем.
- Наличие элементарных ошибок. Под “элементарными” здесь понимаются такие ошибки, которые возникают в основном потоке событий приложения, причем с валидными входными данными. (“Здесь нужно пока не обращать внимания, просто нажмите Отмена, а дальше сначала нажмите Обновить, потом снимите и сразу поставьте обратно эту галочку, а потом уже Сформировать” — представитель заказчика лихорадочно записывает на бумажку). Методика “Мы просто пишем код”, к сожалению, не предполагает затрат труда и времени на альфа-тестирование хотя бы основного потока событий, не говоря об альтернативных потоках.
- Низкое качество кода в плане сопровождения и развития функциональности. (“Нет, эту функцию добавить не получится, тут нужно будет почти все полностью переписать. Почему? Какие сроки были поставлены, вы помните? Поэтому и переписать” — через месяц после запуска. “Кто же это вам такую красоту написал? Руки бы оторвать, тут нужно все переделать с нуля” — через шесть месяцев, от представителя другой команды специалистов).
Почему так?
— Ибо дело, свершенное в спешке, никогда не бывает свершено наилучшим образом.
Памятка руководителю. Опознать методику “Быстро и криво” можно по внешним родовым признакам, даже не заглядывая в код. Вот некоторые из них:
- Соотношение трудозатрат на разработку и отладку не менее, чем 50/50.
- Отсутствие внятных пользовательских инструкций.
- Большое (больше двух) количество итераций “сдали результат — попробовали эксплуатировать — что-то не работает — вернули на доработку”.
- Наличие ошибок, которые обнаруживаются вторым-третьим кликом.
- “Эта ошибка уже была в одной из предыдущих версий, но ее же исправили?”
Нельзя сказать, что подход “Быстро и криво” является абсолютным злом. Существует несколько классов задач, где такой подход действительно позволяет существенно сэкономить трудовые и временные ресурсы.
- Быстрое прототипирование. Проверить гипотезу, понять принцип действия какого-то механизма платформы, попробовать сопряжение с каким-то сторонним API, и так далее. Но здесь нужно четко понимать, что “быстрый прототип” делается на выброс, это даже не временное решение, а просто пробник.
- Ликвидация аварий. При тушении пожара хороши любые средства, и когда система собирается падать (или уже падает), вопросов “насколько грамотно, изящно и эффективно написан подпирающий код” не возникает в принципе. Только нужно не забыть потом заменить вбитые костыли добротной инженерной конструкцией (см. “временные решения”).
- Одноразовые инструменты “для себя”. Когда требуется написать, например, какой-то крохотный корректировщик данных вида “использовал и выбросил”, забивать себе голову альтернативными потоками событий, снижением издержек на сопровождение и другими высокими соображениями абсолютно незачем.
Иными словами, молоток нужен, чтобы быстро забивать гвозди, но далеко не каждая задача представляет собой гвоздь.
Не спеша, эффективно и правильно
Подход посложнее — не спешить с написанием кода, не пытаться выкроить лишний грошик на ресурсах. Разработка даже самого простого механизма, самой элементарной, казалось бы, функции, выстраивается в несколько стадий:
- Анализ. Изучение задачи, изучение текущего положения, выявление противоречий, уточнение неочевидных мест, допущений и ограничений.
- Проектирование. Разработка “на бумаге”. Принятие основных проектных решений (при необходимости с проверкой на быстром прототипе).
- Кодирование. Собственно написание и отладка кода. Честно говоря, это не самое захватывающее занятие — если все продумано и правильно спроектировано, код является очевидным, и очень жаль, что сам себя он писать пока еще не способен.
- Проверка. Прежде, чем передавать какую-то разработку хотя бы на тестирование, разработчик обязан самостоятельно проверить, по крайней мере, основной поток событий и поток наиболее очевидных ошибок.
- Документирование. Написание инструкций по развертыванию, эксплуатации, разрешению известных проблем. Фиксация “на бумаге” наиболее важных и/или сложных проектных решений.
Кажется слегка громоздким, верно? Но все дело в масштабировании. Если мы пишем простенькую обработку, стадии анализа и проектирования можно пройти за десять минут, не написав ни слова, а инструкция будет представлять собой короткую надпись на форме. Важно, чтобы в любом случае все пять стадий имели место, и ровно в указанном порядке.
У этого метода, разумеется, тоже имеются недостатки.
- От разработчика требуется не только квалификация в собственно написании кода, но еще и способность к абстрактному мышлению.
- Что еще хуже, от разработчика требуются также зачатки бизнес-анализа, то есть умение мысленно поставить себя на позицию пользователя. Никакой “работы по четкому ТЗ” здесь не будет, любое ТЗ придется потрошить в поисках противоречий и недоговорок.
- Прямо завтра ничего не заработает. Прежде, чем поехать, какое-то время будем запрягать.
- Эффективная и вдумчивая разработка кажется значительно дороже быстрой и бездумной. Причем кажется не какому-то воображаемому критику, а собственному руководству и представителям заказчика.
Преимущества методики “Не спеша, эффективно и правильно” зеркально повторяют недостатки методики “Быстро и криво”: система устойчива к любым входным данным, соответствует ожиданиям, содержит минимальное количество ошибок (причем некритичных), вполне пригодна для сопровождения, а дальнейшее развитие не потребует переписывать все заново.
Смертельная схватка цены и качества
Казалось бы, вопрос только в цене, которую мы (и наш заказчик) готовы заплатить за качество. Либо “быстро, криво, дешево”, либо “медленно, качественно, дорого” — как нарисовано на всем известной картинке-мотиваторе “Памятка заказчику”.
Так? Не совсем, есть нюансы.
Закон сохранения стоимости
Дело в том, что любая задача разработки по своей сути является чьей-то проблемой. В создание этой проблемы был вложен определенный объем труда. Соответственно, для полноценного решения задачи также потребуется вполне определенный объем труда, и ни одним нормо-часом меньше.
Здесь работает брат-близнец фундаментального закона, названного именами Ломоносова и Лавуазье (хотя кто только этот закон не сформулировал, в европейской истории начиная с Эмпедокла, а в мировой — наверняка еще на стенах пещер царапали). Наиболее же остроумную трактовку фундаментального закона, регулирующего соотношение труда и стоимости, предложил Скотт Адамс в своей замечательной книге “Принцип Дилберта”.
И если разработка ведется поспешно, с низким качеством и установкой “сэкономить на кодировании” — да, это будет дешево, заказчик платит только часть реальной стоимости. Но и взамен получает только частичное решение своей проблемы — как в той старой сказке, где посетитель трактира вдыхал аромат приготовленных блюд, а трактирщик в уплату слушал звон зажатых в руке посетителя монет.
Частичность результата может иметь самые разные формы, например:
- Автоматизированы не все действия, которые могли быть автоматизированы. Как следствие — пользователи затрачивают свое рабочее время на лишние ручные операции.
- Не проверяются входные данные, нет защиты от неправильных действий пользователей. Следствие — множественные ошибки ввода.
- Отсутствуют средства протоколирования. Следствие — невозможно разобраться в причинах некорректного поведения системы (это пользователь ввел что-то не так? или система посчитала неправильно? звезды не так стояли?), для групповых операций невозможно “откатить обратно” или “запустить заново с места сбоя”.
- Код написан и организован таким образом, что добавление любой новой функции и/или модернизация любой существующей требуют затрат, сопоставимых с исходной разработкой.
- Большое количество ошибок в коде приводит к периодическим сбоям и простоям (а это тоже затраты заказчика, пускай и косвенные).
- Ну — и так далее.
Общее во всех этих пунктах — методика “быстро и криво” на стадии разработки закономерно приводит к паттерну “криво, медленно и печально” на стадии эксплуатации.
Можно сравнить с экономией на туалетной бумаге в домохозяйстве, если, конечно, такое сравнение будет уместным. “Экономной” хозяйке кажется, что покупать качественную, четырехслойную бумагу — дорого. Но никто не принимает во внимание, что, если покупать самую дешевую, которая расползается прямо в руках, придется использовать ее на американский манер, сворачивая в шесть рядов. И если посчитать хотя бы квартальный домашний бюджет, по деньгам выйдет примерно столько же, а вот по удобству — да сами попробуйте.
Парадокс убыточного удешевления
Но самое интересное заключается в том, что закон сохранения стоимости имеет только нижнюю планку и в окончательной редакции “для реальной жизни” выглядит следующим образом:
Разработка по методикам семейства “быстро и криво” не может обойтись дешевле, чем разработка по методикам семейства “не спеша, эффективно и правильно”. Но при должном радиусе кривизны может обойтись и значительно дороже.
Это важный момент, и мы разберем его подробно, на конкретном примере из реальной практики автора. Без имен и названий, разумеется (хотя действующие лица, если текст попадется им в руки, без сомнения, себя узнают). Масштаб слегка искажен, и для наглядности, но в первую очередь потому, что NDA нужно уважать.
Место действия — очень масштабный и амбициозный проект по разработке и запуску большой и по-хорошему страшной информационной системы. Один из этапов проекта — перенос (миграция) почти тысячи локальных систем со всеми данными “с земли” в единую систему. “Наземные” системы относятся к нескольким разным типам, из которых только одна реализована на платформе “1С”. Предельно сжатые сроки, чудовищные штрафные санкции за срыв графика, кривые локальные базы, активный саботаж на местах — все, как мы любим.
Инструментарий миграции заказали стороннему подрядчику, своих ресурсов на разработку не было. Но совершили серьезную ошибку — дали подрядчику полную свободу действий. Никто не курировал разработку, никто не проводил аудит промежуточных результатов. Ну а подрядчик подошел к делу творчески, в полном соответствии с поговоркой про сберегающую рубль копеечку.
Концептуальная часть инженерного решения была вполне грамотной. Если мы сводим данные из пяти разнородных систем в одну, разумным представляется разработать некий промежуточный формат, перегонять локальные данные в унифицированные файлы, а затем уже загружать в единую систему. Прекрасное решение, без шуток.
Но вот техническое воплощение этой концепции в личном рейтинге автора по сию пору занимает безусловное первое место в номинации “Быстро и криво”.
Во-первых, в качестве формата для промежуточных данных был выбран файл MS Excel, причем записанный строго определенной версией. Формат, который не обеспечивает даже элементарное “прочитано будет ровно то же значение, которое было записано”. И попробуйте объяснить ответственным за инфраструктуру, что на серверах нужно установить MS Office такой-то, и чтобы можно было вызывать Excel через COM-соединение. Особенно когда чуть ранее была поставлена задача перевести хотя бы часть серверного парка на Linux.
Почему же был выбран самый неудобный формат? Почему не JSON, не XML, даже не xBase? Подрядчик, разумеется, настоящую причину не озвучил. А заключалась она в том, что у “программиста”, которому была поручена реализация, имелись некие готовые механизмы по работе с файлами Excel. И чтобы не писать код заново (а еще, не дай бог, не тратить время на изучение приемов работы с JSON/XML), проще эксгумировать старый код и как-нибудь натянуть его на задачу. Экономия трудозатрат? Ударная скорость разработки? Вне всякого сомнения™.
Во-вторых, было принято техническое решение класса “epic” — не изобретать какие-то свои механизмы загрузки данных, а слегка допилить уже встроенную в типовое решение механику перехода с предыдущей редакции (здесь следует передать горячий привет “правилам конвертации”, и мы не упустим такого случая — “Привет, правила! Идущий к ручью с камнем на шее приветствует вас”). Да, при таком решении весь программный код работы с данными (начиная с чтения *.xlsx) придется утрамбовать в некий “дополнительный обработчик”, то есть в обычный текстовый файл. Да, этот код будет исполняться через оператор Выполнить, и его невозможно будет даже пройти отладчиком. Ну и что? Отладка для трусов, а наши “программисты” настолько круты, что легко находят ошибки методом пристального взгляда. В спагетти-style процедуре размером в полторы тысячи строк.
И в-третьих, на стороне подрядчика никому не пришло в голову, что загрузка единичного файла в настольную, по сути, информационную базу немножко отличается от промышленной загрузки сотен и сотен файлов в единую систему. Что загрузка может быть повторной (нет гарантии, что локальные данные чужеродной системы правильно лягут на парадигму целевой конфигурации с первого раза). Что количество ручных операций и клиент-серверного взаимодействия нужно бы минимизировать. Что помимо техники “начали загружать, обнаружили ошибку в данных, бросили работу с паническим криком” существует еще страшный термин “верификация входных данных”.
Казалось бы, лучшие практики не представляют собой секрета. В самом простом случае:
- Загрузчик на стороне кластера слушает некую директорию.
- Файлы для загрузки подкладываются туда по мере поступления.
- Каждый файл содержит аннотацию (что это, откуда, куда загрузить, кого уведомить).
- Загрузчик держит сколько-то потоков обработки (в рабочее время поменьше, в нерабочее побольше), отслеживает результаты, ведет протоколы и рассылает уведомления.
Просто, как мычание. Но да, такой загрузчик еще нужно написать и отладить. А зачем? Все уже написано. Быстрая разработка предполагает максимальное повторное использование кода.
Пусть специалисты, занятые на процессах миграции данных, вручную запускают клиентское приложение. “Начальная загрузка”, три страницы мастера (настройки всегда одинаковы), выбрать файл, и ждать, когда и чем закончится. Никакого намека на “обработано примерно N%”. Сколько ждать, десять минут, час, пять часов? А что будет, есть десять таких биороботов запустят по семь-восемь потоков загрузки каждый, причем в рабочее время, причем почти одновременно? Инфраструктура, конечно, попробует выдержать восемьдесят сеансов, каждый из которых пишет и проводит сотни (а то и тысячи) документов без всяких пауз. Вкупе с обычной нагрузкой от пользователей единой системы. Вот и посмотрим, а выдержит? Можно даже делать ставки (только админов к тотализатору не допускать, понятно).
Ну а после успешной загрузки нужно также через клиентское приложение зайти в приложение и вручную пройти двадцать две (это не шутка, ровно двадцать две) страницы мастера настройки. Причем значения настроек всегда одинаковые, но изготовить обработку для пакетной установки? Это долго и сложно, в мастере настройки не просто устанавливаются константы, а еще и присутствует некая бизнес-логика. Ну и зачем писать лишний код, если функция доступна и так? Незачем.
Теперь давайте посчитаем, хотя бы в первом приближении, по принципу “на два лаптя правее солнышка”. Трудозатраты на разработку и проверку самого простого пакетного загрузчика, сколько? Пять рабочих дней? Вполне. Но пускай будет десять. И нам потребуется еще техник, который будет вести и контролировать процесс, уделяя этой задаче примерно два часа в день. Предположим, проект рассчитан на год.
Посчитаем (на 2019-й): 80 + (247 * 2) = 574 часа.
Фронт работы в полях: примерно тысяча локальных систем. И почти ни одна миграция не удается с первого раза, и не только по техническим причинам (см. “саботаж на местах”). Возьмем щадящий показатель “2.5 загрузки на систему”, хоть он и занижен. Сколько рабочего времени требуется на одну операцию загрузки? Возьмем еще более щадящий показатель “30 минут”, и это без учета нештатных ситуаций.
Ну а разработку инфраструктурного слоя для загрузчика данных возьмем за честную стоимость, то есть за абсолютный ноль.
Посчитаем: 0 + (1000 * 2.5 * 30) / 60 = ~1250 часов.
Это самая нижняя планка. Понятно, что ставка квалифицированного разработчика несколько выше ставки квалифицированного техника. Но в любом случае себестоимость быстрого и дешевого решения для подрядчика проекта получается вдвое выше, чем себестоимость медленного и дорогостоящего.
Теперь представим, что показатель “количество загрузок на одну локальную систему” составит хотя бы 3.5 (почему? сложная предметная область, множественные ошибки и недоработки в инструментах конвертации, массовое саботирование процесса выверки данных, необоснованные требования повторной миграции, и так далее). И представим, что средняя операция загрузки потребует не 30 минут рабочего времени техника, а ~45 (учтем ситуации “загрузка упала, нужно заново”).
Что получается? (1000 * 3.5 * 45) / 60 = ~2625 часов
В заключение предположим, что фронт работ составит миграцию тысячи локальных систем только в первой очереди проекта, еще семисот во второй очереди, и еще пятисот в третьей. Стоимость придется, как минимум, удвоить еще разок.
Домашнее задание читателю: вычислить, сколько и чего мы в конечном итоге сэкономили на быстрой разработке, на повторном использовании ранее написанного кода и на максимальном задействовании типовых механизмов. Ответ числом, и лучше сразу в рублях.
Парадокс психологии руководителя
Из практики нам (кто работает в отрасли достаточно долго) известно, что руководители всех уровней, будучи поставлены перед выбором между вариантами “Быстро и криво” и “Не спеша, эффективно и правильно”, при прочих равных почти всегда выбирают первый вариант. Почему?
Все просто. Здесь срабатывают сразу две ментальные ловушки: “выгодная цена” и “все будет хорошо”.
Ловушка выгодной цены прекрасно известна всякому, кто хотя бы раз в месяц бывает в универсальных магазинах самообслуживания (они же “сверхрынки”, они же “супермаркеты”). Именно там попавшие в ловушку граждане-экономы покупают годовой запас самой дрянной туалетной бумаги за крайне выгодную цену в 19 рублей 97 копеек.
(В скобках заметим, что гражданин, имеющий базовое понятие о дисциплине “маркетинг”, отдает за туалетную бумагу в четыре слоя с ароматом ромашки 119.97, при этом тратит на элементарную гигиену ничуть не больше гражданина-эконома, но личного комфорта получает на два порядка больше. Ну а любителям лайфхака по имени “бесплатные газеты у метро” хорошо бы загуглить кейворд “свинцовая краска”).
Вот и руководитель, когда смотрит в платежную ведомость или в бюджет проекта, считает очень выгодной идею вычеркнуть из числа “119” первый знак слева.
Ловушка всего хорошего, в принципе, базируется на тех же фатальных дефектах человеческой психики, что и ловушка выгодной цены. Просто “выгодная цена” эксплуатирует уязвимость жадности, а “все хорошее” эксплуатирует уязвимости страха и лени. Мы не любим, когда случается что-то плохое, нам это неприятно. Если же об этом неприятном думать заранее — живот заболит. Да и незачем думать, ну вот что может случиться? Все будет хорошо, этой мысли достаточно.
Да, в прошлый раз тоже делали быстро и криво, в итоге проект провалился в глухой убыток. Но там были совершены грубые ошибки, которые мы обязательно учтем в следующем проекте. Там были новые специалисты, которые еще не освоились, сейчас они уже опытные ветераны. А в позапрошлый раз мы даже получили неплохую прибыль. Правда, это потому, что у заказчика сменился директор по ИТ, и нашу разработку они не стали даже проверять, просто выбросили в мусор. Но мы-то уверены, что все было бы хорошо.
Если отжать из болтовни сухой остаток, получится примерно такая формулировка:
Ключевым отличием профессионального руководителя от линейного является не просто владение методикой управления рисками, но и настоятельное желание применять эту методику в своей повседневной практической деятельности.
Читатель без труда может провести простейший тест на профпригодность своего руководителя любого звена, от тимлида до директора. Нужно всего лишь ненавязчиво поинтересоваться отношением товарища руководителя к работе граждан Тимоти Листера и Тома ДеМарко, изданной под заглавием “Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения”. Если ответом будет изумленное “Что?” поверх стопки покетбуков класса “Очередной Учебник менеджмента или Как повысить продуктивность и креативность работы в команде через геймификацию, хакатоны и гибкие методики”, диагноз можно ставить прямо сразу. Неутешительный, надо признать, диагноз.
Парадокс психологии руководителя заключается в том, что в обычной бытовой жизни руководитель проявляет осторожность и осмотрительность, прекрасно умеет взвесить и оценить риски, управляет этими рисками, причем успешно. Если неопрятный человек цыганской наружности в переулке предложит из-под полы золотую монету по выгодной цене, в обмен на стоимость пары фугасов бормотухи — вряд ли товарищ руководитель понадеется на все хорошее и полезет в свой личный карман за бумажником.
Но в рабочих вопросах почему-то такой подход считается у многих руководителей нормальным и правильным. Если “программист” Петр уверяет, что легко запилит этот трактор за выходные (“возьму старые наработки, уже решал такие задачи”), товарищ руководитель мысленно вычеркивает левый знак из “119”, светлеет лицом и дает трактористу Петру зеленый свет. Доставать бумажник из корпоративного кармана (не говоря о карманах заказчиков) почему-то гораздо легче, чем из своего собственного.
Это не хорошо и не плохо (для инженера вообще не бывает “хорошо” или “плохо”), это просто медицинский факт, с которым нужно считаться. Но не нужно мириться, руководитель, как и любой другой человек, в хорошие дни поддается воспитанию, а в плохие — техникам манипулирования. Развивать тему подробно мы не будем, все же это предмет совсем другой книжки. Заметим только, что разработчик, который не умеет в нужный момент сказать руководителю нужные слова, редко добивается больших профессиональных успехов.
И еще одна важная деталь. Пустые споры с руководством “за качество” никогда не приводят ни к чему хорошему. Любой такой разговор требует тщательной подготовки. Нужно заранее продумать план разговора, заготовить досье, иметь точный перечень, какие и когда были проблемы и потери, провести расчеты, сформулировать аргументы. (На всякий случай, “надоело говнокодить” проходит по ведомству не аргументов, а детского лепета). Руководителя нельзя убедить эмоциями, а вот суммами — можно хотя бы попытаться.
Парадокс эффективной разработки
Нельзя не согласиться с тем, что разрабатывать программное обеспечение не спеша, эффективно и правильно — дело непростое. Ниже по течению книжки мы подробно разберем конкретные практические приемы и реальные примеры, а пока достаточно двух слов: будет непросто.
Попробуем аналогию из мира прекрасного. Например, шахматы. Линейный, назовем его так, игрок знает, как ходят фигуры, знает некоторые правила, возможно, даже знает, как и для чего использовать шахматные часы. Но играет по наитию, как дорогое мироздание на душу положит. Если достались белые, сходим 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). Надеюсь, английский король Георг, первый своего имени, простит автору этот легкий плагиат.
Орденский знак отливается из легких алюминиевых сплавов. Помните, были такие смешные ложки в заводских и школьных столовых? Визуально знак представляет собой греческую букву “Омега”. Вот она:
Как можно заметить, у ордена две степени. “Легкое поведение в сауне” и “Реальная паровая баня”. Посвящение кандидатов проводится строго по канону короля Георга:
- Ночное бдение (над важной и срочной задачей).
- Молитва (“господь всемогущий, пожалуйста, сделай так, чтобы эта хрень запустилась”).
- Пост (никаких печенек до утра, и сахар тоже закончился).
- Финальное купание в ледяной воде (осознание разрушительных последствий своей деятельности, при помощи руководителей и старших товарищей).
Примеры? Сколько угодно. Вот на выбор три кавалера (все истории, разумеется, подлинные, ничего не выдумано).
Мистер Синий. Служил техником на очень большом проекте. Очень торопился завершить рутинную, скучную, но крайне важную задачу. Работа велась через RDP-сессию, и с последним выдохом “ну, наконец-то” гражданин сделал сперва “Пуск”, а потом “Завершить работу”. Поздний вечер пятницы, все админы давно уже в кабаке, номера их телефонов являются коммерческой тайной заказчика. Коллегам, которые на этом же сервере решали свои, не менее важные задачи, или предполагали заняться своими задачами в субботу, было крайне весело. Вторая степень.
Мистер Розовый. Служил в коммерческой конторе на должности DBA, в те лохматые годы, когда в ходу был еще MS SQL Server 6,5, занимался мелкой подстройкой параметров производительности. Где-то вычитал, что можно поместить часть tempdb прямо в RAM, и так загорелся этой идеей, что в спешке не понял метрику. Задал в kb, а там было в Mb. После перезапуска вместо СУБД осталась одно только сообщение об ошибке (в техническом английском гражданин был не силен, и ему показалось, что сервер сказал что-то вроде “ха-ха, тупое ты <много слов 18+>”). Результат: деятельность всего предприятия парализована на весь рабочий день, при лихорадочной попытке переустановить испорчена база данных, крайний backup был двое суток назад. И всего-то пятью поспешными тюками по клавиатуре. Первая степень.
Мистер Зеленоватый. Служил директором по ИТ на большом заводе. Должность громкая, но по сути “главный админ и главный программист”. Очень торопился завершить переезд инфраструктуры на новое железо, даже остался в серверной на ночь. Чтобы не потерять аппаратный ключ, положил в самое надежное место, в карман брюк. А рано утром сел в поезд и уехал в отпуск, в какую-то тьму-таракань. Разумеется, с аппаратным ключом в кармане. Как вы думаете, насколько просто достать ключ на 500 лицензий хмурым утром вторника, будучи рядовым админом на глухом провинциальном заводе, откуда до ближайшего дистрибьютора нужно пилить примерно две сотни верст? Запасного ключа, разумеется, не было (см. “психология руководителя”). Полный кавалер. Один из орденских знаков прицепляется на те самые брюки, только не на карман.
Читатель скажет, админы такие админы, но причем здесь разработка? Нет повода волноваться, уважаемый читатель, дойдет очередь и до разработчиков.
Собеседование в трех гримасах
Почему-то на собеседованиях принято задавать множество различных и зачастую откровенно глупых вопросов. Личный топ-три HR-беспомощности по версии автора выглядит следующим образом:
- Почему мы должны нанять именно вас?
- Кем вы себя видите в нашей компании через пять лет?
- Какими задачами вам интересно было бы заниматься?
Но это тема совсем другой книжки. Если же требуется оценить профессиональную пригодность специалиста не на техническом, а на концептуальном уровне, это можно сделать тоже за три вопроса. Но есть вероятность, что какой-то из ответов вызовет на лице проводящего интервью гримасу, которую опытный соискатель мгновенно расшифрует как “спасибо, мы вам обязательно позвоним”.
Ремесло или творчество?
В нашем сообществе отчего-то бытует мнение, что “программист — это творческая профессия”. Нет ничего более далекого от истины. Внимательный читатель уже заметил, что слово “программист” если и встречается в тексте, то закрывается кавычками, а речь идет только про разработчиков. Именно так, никаких “программистов” во вселенной разработки на стеке технологий “1С” не существует и существовать не может. Мы никакие не программисты, мы разработчики прикладного программного обеспечения.
Ну а кто же тогда настоящий программист? Например, такой парень, который развлечения ради может взять голое железо, написать на асме форт, а на форте лисп. За субботний вечер, под баттл добротного синглмолта и теплый ламповый джаз (автор в свое время был знаком с несколькими такими парнями). Да, они могут писать и на 1Cv8, но это не превращает их в “1С-программистов”.
Не поленимся почтить формальную логику и запишем очередную гранитную формулировку:
Программист запросто может заниматься разработкой программных продуктов, но разработчик программных продуктов вовсе не обязательно является программистом.
Это действительно очень важный момент. Для эффективной разработки прежде всего нужно, чтобы над головой не сиял нимб, а корона с надписью “самый умный парень на деревне” была подогнана по размеру черепной коробки. Если кандидат на позицию разработчика категории “старший” или “ведущий” на вопрос “Ремесло или творчество?” ответит в том смысле, что его профессия безусловно творческая — собеседование можно считать условно завершенным.
Никакого творчества в разработке программного обеспечения нет, и взяться творчеству там неоткуда. Разработка — это безусловное ремесло. Суть процесса разработки заключается в том, чтобы
- Распознать задачу и декомпозировать до необходимого уровня.
- Выбрать из набора уже известных паттернов нужные.
- Временно забыть про все остальные.
- Недостающие паттерны найти, изучить и включить в свою ментальную библиотеку.
- Несуществующие, но необходимые паттерны изобрести, запомнить и поделиться с коллегами.
- Разработать необходимое программное обеспечение, применяя правильные паттерны к отдельным компонентам задачи.
“Изобрести”, понимаете, а не “сотворить”. Хайрем Максим и Дуглас Энгельбарт (эрудированный читатель может подставить имена своих любимых инженеров) не были творческими людьми, они не творили, а изобретали и конструировали. Даже Леонардо, когда пересаживался с мольберта на тогдашний аналог кульмана временно переставал быть человеком творческой профессии.
В слове “ремесленник” нет ничего плохого и унизительного. Это гордое слово. Быть настоящим ремесленником означает быть мастером своего ремесла, мастером своего дела. Пугаться этого слова не нужно. А вот граждан, у которых при написании программного кода над головой сияет творческий нимб, автор, как бы это сказать помягче, слегка опасается видеть в непосредственной близости от своих рабочих задач. Ремесленнику с творцами если и по пути, то разве что по пути в кабак или чайный домик.
Вы человек творческой профессии? Спасибо, мы вам обязательно позвоним.
Олимпиада или производство?
Ясно даже и ежу, что любому сколько-нибудь вменяемому разработчику, безусловно, яркая олимпийская соревновательная деятельность интереснее и приятнее скучного производства с его станками, гудками и планами выпуска. Но у этого вопроса есть довольно глубокое второе дно.
Олимпийский стиль разработки предполагает, что целью является решение конкретной задачи, и только этой задачи. И решение должно быть рекордным. Самым быстрым, самым изящным, самым остроумным, самым компактным, самым <подставить любое слово>. Ни о каком сопровождении и развитии речи не идет даже близко. Наоборот, обычный линейный специалист даже и не поймет, почему написанный олимпийским небожителем код вообще работает. В таком коде страшно тронуть даже комментарий, который состоит из одного слова (три буквы, средняя “у”, не “душ”).
Почему же олимпийский стиль для эффективной разработки есть безусловное зло и беда (а это именно так)? Попробуем призвать на помощь добрую фею Аналогию из мира прекрасного, то есть из военной истории. Три кейса, на выбор.
- Беспосадочный перелет экипажа АНТ-25, выполненный под командованием Валерия Чкалова из Москвы до Ванкувера через Северный полюс. 1937-й. Авиация Красной Армии наглядно показала американским коллегам, что сможет прислать бомбардировщики почти в любую точку на мировой карте.
- Рейд американских базовых бомбардировщиков Б-25 на Токио с использованием авианосца “Хорнет”, выполненный под командованием подполковника Джеймса Дуллитла. 1942-й. US Army наглядно показала японским коллегам, что может достать до Токио, даже лишившись всех баз в Тихом океане.
- Переход американского низкобортного башенного броненосца “Миантаномо” через Атлантический океан в Европу (фамилию командующего автор, к сожалению, на память не знает). 1866-й. US Navy наглядно показал коллегам из Royal Navy, что сможет подогнать пару-тройку своих монстров прямо в гавань Плимута.
Эти три кейса очень похожи, в каждом из них решалась и была успешно решена задача не просто рекордная, а героическая, без всяких шуток. Задачи класса “unreal”. Но есть и еще кое-какие общие черты:
- Для выполнения задачи требовалась длительная, масштабная и очень дорогая подготовка.
- Используемая техника либо вообще не была серийной, либо была усиленной и работала далеко не в штатных режимах.
- Выполнение задачи имело целью повысить моральный уровень своих военных и оказать моральное давление на военных противника.
- Никакой практической пользы от выполнения рекордных задач не последовало.
- Попыток повторения никогда более не предпринималось, каждая задача была решена в единственном экземпляре.
И что характерно, каждый рейд сопровождался запредельным риском и закончился успехом благодаря каким-то чудесам природы и человеческой выносливости. Не случись тех чудес, и первые, и вторые и третьи закончили бы свой олимпийский путь на океанском дне, вместо героического триумфа получился бы стыд и позор, а враги по такому прекрасному поводу задали бы праздничный банкет.
Вот поэтому олимпийские рекорды хороши только на своем месте и в свое время. Для эффективной разработки программных продуктов олимпийский стиль не годится уже хотя бы потому, что результаты не получится тиражировать, даже если HR-служба найдет на рынке труда героев Олимпа.
Небольшой disclaimer. Автор вовсе не против олимпиадного программирования. Как и любые части олимпийского движения, они ориентированы прежде всего на вовлечение молодых людей в нашу профессию, в нашу индустрию. Но важно не забывать, что первая фраза мастера, обращенная к новому подмастерью, на любом языке звучит как
— Забудь все, чему тебя учили раньше. Здесь ты будешь учиться работать.
Этот совет верен и правилен даже когда у подмастерья на рабочем столе красуется золотая олимпийская медаль.
Производственный подход по сравнению с олимпийским должен казаться скучным. В нем нет (или почти нет) места героизму, рекордам и овациям. Даже когда на производстве совершается нечто героическое, кроме ближайших коллег никто и никогда об этом не узнает, и даже простого “спасибо” ожидать не стоит. Но не стоит по этому поводу грустить, наше ремесло устроено по крайне простому принципу:
— Мы работаем за деньги. Решаем технические проблемы заказчика и создаем для него материальные.
Давайте попробуем перечислить родовые признаки эффективной разработки в производстве. Вот они:
- Целью производственной деятельности не является решение каких-либо задач.
- Целью в коммерческом производстве является извлечение прибыли.
- В некоммерческом производстве (если такое вообще бывает) цель описана соответствующим положением Устава.
- Любая задача по разработке программного обеспечения решается с прицелом на дальнейшее развитие, дополнительную продажу, возможность тиражирования.
- При разработке программного продукта уже на этапе эскизного проектирования сразу принимается во внимание фактор эксплуатации:
- Необходимость сопровождения специалистами не очень высокой квалификации.
- Необходимость устойчивости к изменениям в окружении, в самом широком смысле слова “окружение”.
- Снижение лишних издержек везде, где только возможно.
Иными словами, при производственном подходе разработчик задается не только вопросом “как это запилить поизящнее”, а еще и “насколько дешево, просто и удобно будет это сопровождать, расширять и развивать”.
Фабричный гудок, разумеется, звучит не так ярко и бодро, как “We are champions” (и автор позволит себе мелкую пакость, указав, что эту песню по канону поют до выхода на бой, и уж никак не после победы). Но дела на фабрике идут, контора пишет, касса выдает деньги, день за днем, месяц за месяцем. Олимпийское же золото абсолютному большинству чемпионов доведется увидеть либо в сладком сне, либо на груди более успешного противника.
Вы из тех благородных героев Олимпа, которые из последних сил рвут противника и сверкают золотом? Спасибо, мы вам обязательно позвоним.
Техническое задание или технический проект?
У этого вопроса даже не двойное, а сразу тройное дно. Первый смысловой слой, а в чем, собственно, разница, если она вообще имеется? Для граждан, исповедующих религию “просто пиши код”, разницы, разумеется, никакой нет. Будь автор сородичем ехидны, непременно бы заметил, что в руках “просто пишущего код” любой язык программирования со временем неизбежно превращается не просто в Brainfuck, а в Oook! — но автор человек вежливый и ехидных замечаний, конечно же, себе не позволит.
Предположим, что соискатель все-таки осознает, что написание кода при промышленной разработке сопровождается какими-то внутренними техническими документами. А также понимает разницу между рабочей перепиской и бюрократическими отписками, между пустой болтовней в переговорке и рабочим совещанием, между разбором полетов и начальственной руганью, между холиваром и защитой концепции, между... Извините, автор слегка замечтался.
Второй смысловой слой ставит перед соискателем ловушку выбора. Вот вы, юноша, как предпочитаете — по техническому заданию, или с техническим проектом? А учитывая, что задание четкое, а проект размытый? А как по-вашему, можно ли совместить? Маленькие радости для любителей ставить простыми вопросами незнакомых людей в неуютное положение.
Как перевести “предпочитаю работать по четкому ТЗ” на русский язык? Очень просто. Кто-то должен взять бумагу и написать пошаговую инструкцию — какие объекты создать, как и что расположить на форме, какие действия должны выполняться системой в ответ на действия пользователя, ну и еще сотня разных подробностей. Возникает вполне логичный вопрос, если все уже продумано, расписано, разжевано и в рот положено — а зачем нам вообще разработчик? С выполнением пошаговой инструкции справится даже школьник выпускного класса, не говоря о студентах первого-второго курсов. Какие у нас там заявлены ожидания по зарплате? Спасибо, мы вам обязательно позвоним.
Эффективная разработка не допускает существования “технических заданий” и четко разграничивает компетенции сбора требований, системного анализа и технического проектирования. Почти полная аналогия с “Game of Thrones”, первым делом строим Великую Стену. За Стеной — всякая жуть и нежить, заказчики со своими одичалыми требованиями, там действуют наши отважные разведчики из департамента бизнес-анализа. А по теплую сторону Стены стоят наши рабочие станции, клацают кнопки, запиливается и тестируется программный код. Для полноты образа не хватает разве что лорда-командующего, в черном кабинете, на самой границе света open-space и мрака competitive-market.
Ключевое отличие техпроекта от техзадания — задание попадает к разработчику откуда-то, а технический проект разработчик ведет и пишет самостоятельно. Структура, объем и сложность текста, необходимость иллюстрировать текст схемами, диаграммами, все это определяется сложностью и масштабностью задачи. Для какой-то задачи весь техпроект уложится на один лист, для какой-то другой один только блок “Анализ” займет сотню страниц с двумя десятками таблиц и рисунков. Важно, что технический проект разрабатывает именно тот специалист, который будет отвечать за разработку продукта. Не обязательно в единственном числе, если задача по-настоящему большая, над техническим проектом работает вся команда.
Разрабатывать без технического задания вполне можно. Без технического проекта — нельзя.
А вы, юноша, умеете в техническое проектирование? Поясните, пожалуйста, в чем разница между Activity Diagram и Sequence Diagram? А что так, не любите UML? Все верно, незачем. Рисуешь кривые картинки, как Пикассо, а их потом никто и не смотрит. Спасибо, мы обязательно вам позвоним.
Если звонилку найдем, конечно.
Кофе-пауза #2
Как любил говаривать любимый философ автора мсье Монтень, добродетель, перейдя границы разумного, оборачивается пороком. Этот принцип является универсальным и может быть использован абсолютно в любой отрасли деятельности вида homo sapiens. Мы попробуем рассмотреть границы разумного на примерах строительного мастерства, наша добрая фея Аналогия из мира прекрасного отчего-то считает, что где строительство, там и разработка программных продуктов.
Как и любой серьезный разговор за чашкой кофе, начать следует с пары замшелых шуток. Выбор автора в таких случаях сводится к старой доброй шутке про точное соблюдение технических заданий. Строительная площадка, дело идет к приемке, но сперва репетируют. В роли представителя заказчика выступает опытный инженер-строитель из дружественного треста. Подрядчик демонстрирует удивительное сооружение: на прибрежном холме выкопана круглая шахта глубиной тридцать метров, облицованная внутри железобетоном, на дне установлен очень мощный прожектор.
— Э… Юноша, что вы мне такое показываете?
— Сам не очень понимаю. Но все сделано точно по ТЗ, вот чертежи.
— Э… (переворачивает чертежи) Вам не кажется, что они заказывали маяк?
А теперь серьезно™. В текущей реальности попадаются далеко не шуточные примеры творческого подхода к строительному мастерству. Например, что бывает, если творчески прогуливать дисциплину “сопротивление материалов” (дичайше скучные лекции, с этим не поспоришь, автора эта горькая чаша миновала, но коллеги рассказывали). Без имен и названий, но ни слова не приукрашено.
Первый объект строительства — крупный деловой центр, оформленный в стиле “космический модерн”. Что-то вроде звездолета “Энтерпрайз NSS-1701-D”. Одной из фишек были скоростные лифты в металлических шахтах-колоннах. После монтажа лифтовое оборудование следовало проверить, так что выполнили пробный пуск. С первого этажа сразу до верхнего. И выяснилось, что проектировщик банально не предусмотрел отвод воздуха из этих своих космических шахт. Ну а лифт в такой шахте действует примерно как поршень велосипедного насоса. В соревновании пневматики с прочностью металла победила стихия воздуха, все лифтовые двери оказались выбиты и разломаны. К счастью, никто не погиб и не пострадал.
Второй объект строительства — многоквартирный жилой дом класса “люкс”. Проектировщик предусмотрел в каждой ванной комнате место под установку джакузи. И вроде бы даже выполнил какие-то расчеты. Но не учел буквально сущую мелочь:
- Владельцы квартир класса “люкс” и джакузи покупают класса “люкс”, большие и очень тяжелые.
- Дом спроектирован так, что все “места для установки джакузи” расположены строго одно над другим.
- В отличие от ванны, которая наполняется жильцами разных этажей редко и нерегулярно, в джакузи все залезают примерно в одно время.
- В джакузи, как ни странно, наливается вода, и что еще страннее, эта вода имеет ненулевой вес.
Расчеты оказались слегка оптимистичными, ну а подрядчик, как это водится на строительстве объектов класса “люкс”, экономил на всем, на чем только возможно, в том числе на качестве материала и квалификации проектировщика, в один прекрасный день приключился второй раунд состязания сил природы с технологией строительства. Гидравлика испытала прочность бетона, и победа осталась за стихией воды. К счастью, никто не погиб, но руки-ноги у некоторых оказались поломаны.
Ну и третий, к счастью, не объект, а проект строительства. Эту историю автору поведал гражданин, который сам не строит, а занимается надзором. К ним как-то пришел, скажем так, экономически активный южный гость северной столицы и принес на утверждение проект жилого дома, который планировалось возвести в одной из ликвидируемых на тот момент окраинных промышленных зон. Проект был всем хорош, за исключением традиционного у определенного класса предпринимателей экономичного подхода к персоналу. И если класть кирпичи можно научить и медведя, то ставить на проектирование недоучку слегка рискованно. В доме не была предусмотрена вентиляция. Вообще. Никакая.
В результате краткой и не очень цензурной экспертизы будущий заказчик строительства покинул контору в твердой уверенности, что у него просто вымогали взятку. Всем же известно™, что чиновники ничего другого и не умеют. Что дальше стало с этим проектом, знает один только черт, но страшных историй про дом-душитель по Петербургу тех времен вроде бы не ходило.
Как говорит нам один старый-престарый баян, какое же счастье, что программисты не строят дома. Иначе первый же случайно залетевший дятел разрушил бы всю нашу вековую цивилизацию.
Три простых способа все испортить
Где-то выше по тексту автор позволил себе довольно злую шутку про “геймификацию, хакатон и гибкие методики”. Сейчас будет еще хуже, сейчас эта шутка получит расшифровку.
Как превратить работу в детский утренник
Посмотрим словарное определение термина “геймификация” (первый попавшийся сайт, к сожалению, в приличных словарях такого слова нет).
Геймификация — это когда серьезные сервисы и приложения используют наработки из игровой индустрии (игровые механики) для вовлечения, удержания пользователей и многого другого.
В нашей с вами отрасли обычно практикуют геймификацию курильщика. Происходит это примерно так. Вот наш флагманский продукт, который мы запиливаем. Вот наши разработчики: Петя, Митя, Миша и Маша. Вот наш баг-трекер, в котором записаны многие сотни ошибок. А вот наша HR-затейница Жэ (Жанна Эдуардовна, а не то, что подумал читатель), которая читала модные книжки и даже ходила на специальные курсы. Жэ вешает на стену красивую большую бумажку с фотографиями разработчиков. Каждую неделю ведется подсчет, кто сколько ошибок исправил. Лидер получает: а) звездочку на бумажку; б) маленький тортик со свечкой; в) хоровое исполнение “Сколько багов ты исправил, и какой ты, Миша, молодец” на мотив “Happy Birthday” в исполнении всего опенспейса. Можно и вприсядку, с прихлопом.
Если звездочка вторая подряд, она золотая, если третья, то рубиновая. Четыре подряд дают приз в формате плюшевой симпатяшки. Каждый месяц результаты обнуляются, но победителю месяца выдают почетную грамоту и флажок на рабочий стол. Лепят звездочку уже на другую бумажку, где идет соревнование за годовой трофей. Большая (реально большая) плюшевая симпатяшка, корзина (буквально) конфет и пара билетов на шоу трансвеститов модного исполнителя. Ну а если у нас разработчиков не четыре, а двести сорок четыре, можно закрутить такие схемы, что придется написать книгу правил.
Бывает ли что-нибудь тупее? Затейница Жэ возразит, что ей поручили мотивировать разработчиков на исправление ошибок, а то им неинтересно. Само собой, кому интересно ковыряться в чужом копролите? Ну то есть суммы в платежной ведомости этих милых молодых людей не мотивируют никак, для выполнения рабочих задач перед ними нужно водить хороводы. И вместо того, чтобы решать задачу “снизить количество ошибок и усилить контроль качества” компания (за свой, заметим, счет) решает зачем-то задачу “потеребить железу детской радости у разработчиков, авось они будут стараться чуточку сильнее”.
Наша добрая фея Аналогия из мира прекрасного подсказывает прекрасный исторический пример. Адмирал Зиновий Рожественский в своем знаменитом походе тоже немного практиковал геймификацию для угольных авралов. Чтобы придать командам резвости, на каждую погрузку назначалась денежная премия за скорость. Причем премию честно делили на всех, и при ударной погрузке на матроса приходилось не меньше рубля, а для нижних чинов это существенные деньги. И разумеется, в слове господина капитана, отдающего рапорт о принятом тоннаже, господин адмирал сомневаться не имеет права.
Когда же перед решающим участком похода и возможным генеральным боем Зиновий Петрович устроил ревизию, оказалось, что господа офицеры все поголовно занимались приписками. И что приписывал даже “Александр”, который на эскадре считался эталоном честной службы и чем-то вроде лейб-гвардейского корабля. Кстати, именно “Александр” премиальных денег получил больше, чем все остальные.
Вопрос — если адмирал не может доверять своим капитанам даже в такой мелочи, как 15 копеек за принятую тонну топлива, то как можно доверять им в бою? Аналитики сходятся на том, что разработанный Рожественским план боя “держать генеральный курс 23°, в случае выбытия флагмана колонну ведет следующий мателот” (и это весь план сражения, почти дословно) имел причиной не клиническую тупизну Зиновия Петровича, а тотальное адмиральское недоверие командирам кораблей.
Созревшие плоды мотивирующей геймификации были собраны в финале похода, каковой финал остался в мировой истории под именем “Сражение в Цусимском проливе”.
С разработчиками, вы не поверите, бывает ровно так же, как и с морскими офицерами. Если мотивируют на количество или скорость, вместо вдумчивой планомерной работы возникает соблазн найти путь полегче и побыстрее. Как результат, мусор из кода никто не убирает, мусор просто заметается под ковер. Ошибка вроде бы исправлена, даже тестировщик верифицировал. Правда, при этом появились две новые ошибки, но пока их заметят, пока опишут, можно получить два-три тортика и украсить стол плюшевым пушистиком.
Хотя, казалось бы, нанять чуть больше людей, учредить обязательный аудит кода (пары “кодер/аудитор” меняются каждую итерацию), и объявить по команде, что если за квартал количество актуальных ошибок будет снижено до N, но без ущерба для плана выпуска, команда получит квартальную премию в размере M% квартального ФОТ. Звездочки тоже можно лепить, только не золотые, а коричневые. Каждый отказ вида “отдал исправление на проверку, вернули на доработку” добавляет балл. У кого больше баллов, тому недельная звездочка. А победителю месяца вместо наградной чайной кружки с принтом торжественно вручать розовый дилдо в подарочной упаковке, механический, но без батарейки.
Вот это будет геймификация взрослого, здорового человека. И результат, что характерно, ждать себя не заставит.
Как превратить работу в штурм крепости
Следующий способ называется “хакатон”. Если попробовать угадать по звучанию, получится что-то бактериальное, сродни холерному вибриону. Посмотрим словарное определение:
Хакатон (англ. hackathon, от hack и marathon — марафон) — форум разработчиков, во время которого специалисты из разных областей разработки программного обеспечения (программисты, дизайнеры, менеджеры) сообща работают над решением какой-либо проблемы. Сегодня хакатоны уже не относятся к хакерству, это просто марафоны программирования. Обычно хакатоны длятся от одного дня до недели.
На практике “хакатон” это несколько дней труда в ударном ритме, без анализа, планирования и проектирования. Результат, как таковой, не важен, важно попробовать “воплотить идею в коде”. Почти во всех компаниях, выпускающих свои продукты по графику, ближе к плановой дате релиза можно наблюдать подобие хакатона. Все причастные сидят допоздна, обедают урывком, некоторые даже остаются на ночь, чтобы не тратить драгоценное время на дорогу. Ну а официальный хакатон это такая же тараканья гонка, только не за дедлайном, а за призом. В качестве приза участники получают запиленный с максимальной скоростью и максимальной же небрежностью прототип чего-то, что может стать продуктом, овердоз адреналина, спонсорские печеньки.
Такой стиль работы, кстати, активно практикуется на Корейском полуострове. И не для решения каких-то трудовых подвигов, а в обычной, повседневной деятельности. На Севере это называется “сокточжон” (по-русски “скоростной бой”), на Юге ровно тот же подход именуется “ппалли-ппалли” (что-то типа “давай-давай”). Если читатель, по примеру автора, будет иногда читать северокорейские новости (доступны на русском), то заголовок
Сегодня товарищ Ким Чен Ын ведет скоростной бой за качество на заводе по производству крепкого алкоголя.
не будет выглядеть ошибкой переводчика. А соль этой шутки в том, что “скоростной бой” ведется за качество. Какое качество получается, когда исполнитель видит в задаче врага, которого необходимо уничтожить как можно скорее, работая в темпе даже не вальса, а урагана?
В производственном языке Союза метод хакатона называется “штурмовщиной”, и слово это было ругательным. Руководителей за штурмовщину критиковали, в том числе и по партийной линии. Почему? Потому что хакатон — это дистиллят семейства техник и методик работы “Быстро и криво”. Об этом сказано даже в самом названии. Что есть “хак”? Это либо использование недокументированных возможностей, либо внесение изменений на тех участках системы, которое для этого категорически не предназначены. Ну а “марафон” — это просто спортивная забава, забег на очень длинную дистанцию.
Можно ли решить сложную инженерную задачу методом коллективного штурма? Всякий опытный инженер после получения вводной скажет что-нибудь вроде “требования вроде бы понятны, теперь с этой задачей нужно переспать, продолжим завтра”. Скоростное написание кода само по себе не имеет никакого смысла, смысл имеют проектные решения. Когда проектные решения принимаются в спешке, без анализа, критики и защиты, такие решения почти всегда оказываются плохими. Но раз код уже запилен, значит уже не выбросить, и будем делать из этого продукт. Это ничего, что множество важных второстепенных функций не продуманы, и придется их потом запиливать по живому. MVP у нас уже родился, а рисовать модельки — это для дураков. Пусть и багов в нашем MVP, как в кухмистерской образца XIX века, со временем поправим. Уже можно продавать.
Хуже всего, когда хакатоны устраивают для студентов и молодых специалистов. Вместо того, чтобы приучать людей, в чьих головах пока еще гуляет ветер свободы от знаний и опыта, к планомерной работе и эффективной разработке, дается установка
— Не нужно ничего планировать, проектировать, анализировать и оценивать. И запомните, дети, не бывает системы, которую нельзя было бы написать за выходные.
Потом такой “марафонец” приходит в реальную команду и запиливает за условные выходные механизм, который затем более опытные коллеги в течение нескольких лет пытаются привести к рабочему виду. Примеры таких механизмов и продуктов из “вселенной 1С” известны каждому опытному разработчику, и не стоит тратить время и бумагу на их перечисление.
Не стоит забывать и о побочных эффектах. Хакатон требует максимального напряжения умственных и физических сил (голова думает отнюдь не бесплатно). Разумеется, дело не обойдется и без легких веществ в ассортименте. Кофе, “энергетические” напитки, сахар в огромных дозах. Если наложить это на двухдневное недосыпание, заниматься только разработкой, и чтобы все вокруг занимались тоже только разработкой — возможно, в финале действительно можно получить что-то вроде интеллектуального оргазма. Но нельзя забывать про посткоитальный синдром, после напряжения неизбежен довольно длительный период упадка сил.
Что мы получаем в сухом остатке? Потратили несколько дней, быстро и криво запилили что-то, что по-хорошему должно быть выброшено, и просадили свою продуктивность и производительность примерно на неделю вперед. Но зато — хорошо посидели, познакомились с очень интересными коллегами, прекрасно провели время. Хакатоны не имеют отношения к работе, это чисто спортивные мероприятия. Никто, кроме лорда Черчилля, не утверждает, что спорт вреден для больных и бесполезен для здоровых.
Напоследок наше любимое сравнение со строителями. В некоторых соседних странах бывают строительные состязания в олимпийском стиле. Скоростная укладка кафельной плитки, например. Даже национальный чемпионат проводится. Теперь вопрос, точнее выбор. Бригада “Эх” работает нудно и скучно, по каким-то чертежам, что-то там вымеривает, подсчитывает, устраивает долгие перекуры. Бригада “Ух” кладет плитку на скорость, без сна и отдыха, на ходу запивая сладкие пончики газировкой с кофеином и таурином. Интересно, какую из бригад уважаемый читатель наймет для ремонта своего личного дома?
Как согнуть работу в бараний рог
Разумеется, слово “гнуть” в заголовке поставлено не случайно. Речь пойдет о модных “гибких методиках разработки”. Автор дает честное слово, что не хочет сказать ничего плохого про Agile и всевозможные производные. Наоборот, использует или пытается использовать какие-то элементы в своей производственной деятельности. Речь пойдет о том, что у каждой методики есть теоретическая база и практическая применимость к решению тех или иных задач разработки (сон разума “Agile-управление министерством путей сообщения” мы рассматривать не будем).
Есть старая инженерная шутка про теорию и практику. Вот она в применении к Agile при разработке софта:
Теория — это когда все знают, почему нужно работать именно так, но никто так не работает. Практика — это когда никто не понимает, как правильно работать, но как-то по интуиции работают примерно так, как нужно. Здесь, в нашей могучей корпорации, мы соединили практику с теорией. У нас вообще никто не работает, и мы абсолютно не понимаем, почему.
В каждой шутке содержится только доля шутки. У любой управленческой методики есть границы применимости. Простейший пример: соединить гибкую методику разработки с гибким рабочим графиком.
Что получится? Петя приходит ровно в семь тридцать утра, он жаворонок, автомобилист и любит пустые дороги. Митя приходит не раньше часа дня, он по натуре сова и легко может просидеть на работе до часу ночи. Маша девушка аккуратная, но ей нужно отводить в детский сад ребенка и потом долго ехать, поэтому она материализуется обычно к одиннадцати. Наконец, Миша слегка непредсказуем, может опоздать на пять минут, а может и на четыре часа. И когда нам проводить стендап, в обед, чертить вилкой по тарелке? И какой тогда в этом стендапе смысл? Руководитель (“мастер”, если хотите) гибкой методикой добился только того, что перестал понимать, как и с каким результатом его команда провела вчерашний рабочий день. Информация в команде передается не через четкий ежедневный ритуал, а на бегу, по принципу певчих птиц, один чирикнул, другие разносят по лесу.
Или вот еще неплохой совет начинающим осваивать гибкость руководителям. Сделать длительность итерации плавающей. Скажем, по уставу команды это две недели, но если руководитель очень занят и не получается выделить несколько часов на ретроспективу, то перезапуск итерации можно и подвинуть. Какой смысл был планировать задачи на две недели, если сопоставление плана с фактом производится через пять? Большая часть задач, которыми занималась команда, не входила в план итерации, а была поставлена на ходу. Что и как мы сможем оценить в ретроспективе, какие сможем сделать выводы? Никаких, кроме “ну, вроде мы молодцы, кажется, что тратим время с пользой”.
Ну и на третье. Все знают™, что изюминкой гибких методик разработки является переход от крупных “длинных” релизов к более частым и “коротким”. Для разработчиков, безусловно, такой подход может быть удобным. Но если немножко подумать о том, а зачем вообще пишется софт, можно прийти к интересному выводу. Понимаете, товарищи разработчики, пользователи, как бы это сказать мягче, ненавидят частые изменения и обновления. Особенно в таких консервативных отраслях, как фискальный и управленческий учет. Абсолютное большинство пользователей ненавидит обновление, которое привносит в систему ненужные им функции, но не привносит исправление старых ошибок. Пользователи многих типовых и отраслевых продуктов при слове “обновление” забиваются в угол, поднимают на загривке шерсть, шипят и скребут когтями. Не верите — добро пожаловать в поля, то есть во вселенную сервисного обслуживания конечных пользователей.
Памятка руководителю. По твердому убеждению автора, любой, кто претендует на позицию разработчика, должен либо иметь опыт работы в полях на линейной должности, либо пройти производственную практику, никак не меньше месяца. Пусть поработает младшим сервисным техником, оператором горячей линии, просто оператором в обычном отделе. Пусть пообщается с линейными пользователями, и чтобы они не знали, что человек из разработки, стажер и стажер. Подобная полевая практика неплохо прочищает мозг начинающего разработчика от фантазий, которые некоторые уважаемые руководители проектов и департаментов именуют “эротическими”. Нафантазировать можно свистелку о тридцати двух стволах, в форме красного котика верхом на желтом драконе, и кто-то из пользователей обязательно будет в полном восторге. Угадайте, что скажут остальные.
Подобных паттернов загибания рабочего процесса до состояния бараньих рогов (по мнению автора, применять управленческую методику с точностью до наоборот означает добровольно признать некоторую степень родства с этим благородным животным) можно привести великое множество.
Прекрасный пример можно вынуть буквально из кармана. Мобильное приложение Facebook для операционной системы Android. Эта чертова штука обновляется по два-три раза в неделю. И почти каждое обновление меняет что-то в интерфейсе. Как-то за месяц расположение и вид основных кнопок (а их всего-то четыре) менялось четыре раза. И при этом уже несколько лет не могут победить какой-то фатальный баг с локалью, из-за которого периодически весь интерфейс становится англофонным. Говорить о проблемах производительности и синхронизации данных применительно к Facebook это примерно как в ноябре в двухсотый раз обсуждать двухсотый оттенок серого петербургского неба. Но зато с гибкостью разработки у детей Марка Цукерберга наверняка полный порядок.
Методики и техники Agile — прекрасная, мощная штука. Выстроить эффективную разработку без хотя бы фрагментарного применения этих методик попросту невозможно. Но соединять теорию с практикой нужно таким образом, чтобы: а) все понимали, почему работать нужно именно так; и б) все именно так и работали.
Для начала же следует перестать считать “гибкие методики” чем-то новым. Неужели кто-то думает, что если перевести слово “планерка” как “stand-up”, “разбор полетов” назвать “ретроспективой”, у слова “демонстрация” отрезать три нижних слога и написать огрызок транслитом как “demo”, месячный план записать набегающей волной на две “итерации”, ну и так далее, от этой словесной чехарды старая советская инженерная и управленческая методика заиграет какими-то новыми красками?
Хотя, кто знает? Попробуем называть старую добрую вечернюю прогулку “позитивной аэробной кардио-нагрузкой”, это должно произвести неизгладимое впечатление на артериальную гипертензию.
Кофе-пауза #3
Эта история вспоминается автором всякий раз, когда коллеги в кофе-румах заводят жаркие разговоры о феноменальном развитии новомодных технологий “big data”, “deep machine learning”, “blockchain”, “беспилотность” ну и сверкают разными другими гранями вопроса о сортах расцветающих на Марсе яблонь.
История относится к лохматому 1998-му году, когда государство, по крайней мере, в Петербурге, попыталось поставить производство алкоголя хотя бы под какой-то контроль. Те славные времена первоначального накопления капитала, когда в ночном ларьке пролетарий мог купить две жестяные банки с “водкой” по цене одной, рядом стоял ларек, где жарили “шаверму”, между ними располагался прибор для “игры в столбик” (простейший аналог “однорукого бандита”).
Автор тогда трудился на посту начальника отдела ИТ в ЗАО “Санкт-Петербургская Алкогольная Компания”, и название вовсе не было громким. Крупный опт, поставки на половину города. И вот в рамках ужесточения контроля всех участников процесса обязали сдавать дополнительную отчетность, в которой нужно было перечислять номера акцизных марок. Проблема была в том, что разные заводы применяли разную логистику, и в одной из фур все номера шли по порядку, а в другой как кладовщику белочка напела. Приходилось нанимать десяток-другой студентов, которые перебирали каждую поступающую бутылку и писали номера в тетрадочку. Тетрадочки сдавали операторам, и несколько человек тупо перебивало циферки с бумаги в базу данных.
У нас, разумеется, возникла гениальная в своей простоте идея автоматизировать процесс. Всего-то и нужно было, что реализовать свою систему распознавания рукописного текста. Тогдашний FineReader нужную точность не тянул, а цена ошибки, учитывая, куда потом направлялись результаты, могла быть очень высокой. Но на счастье, у нас в команде был Миша, и был Миша не просто золотым выпускником математической школы, но и программистом от бога. Миша запилил нам распознавалку (только цифры). И эта маленькая смешная штука уделала по точности FineReader, как сейчас маленький смешной Sherp делает монстров на водном оффроаде, если вы, конечно, понимаете, о чем это автор тут завернул (читатель, который любит в машинки и не поленится загуглить, не пожалеет).
И вот Миша как-то представил в лицах свой разговор с бывшим то ли одноклассником, то ли однокурсником, назовем его условно Петром. Петр поддался утечке мозга и уехал работать на дядюшку Билла, в Редмонд.
— Ну и чем ты сейчас занят в MS? Интересные, наверняка, задачи.
— Да фигню какую-то пишу на Java. Даже не знаю, в какой проект. Так, взять отсюда датасет, перевернуть и положить вот сюда. А у тебя что?
— Да так, небольшая задачка. Распознавание рукописного ввода на нейронной сети, с машинным обучением.
— Это что, в НИИ каком-то? О_О
— Не, Алкогольная Компания.
— Какая-какая компания? О_О
— Алкогольная. Ну, водкой торгуем, оптовая база.
— (стук падающей на пол челюсти)
Распознавалку, что характерно, довели до вполне промышленного релиза, оформили как внешнюю компоненту для тогда еще 7.7 (на сетевых просторах наверняка где-то можно найти, “OCR Pelican”). Но до внедрения дело не дошло. Почему? Во-первых, точность все-таки была не 100%. Во-вторых, требовался промышленный потоковый сканер, а его стоимость была сопоставима с ФОТ всех занятых на ручном вводе операторов на несколько лет вперед. Скажем так, идея опередила свое время.
Если учесть, что “решить задачу машинного зрения” некий профессор в MIT ставил как задачу выпускникам на летнюю практику еще до рождения автора этих строк, в самую первую AI-лихорадку, такие идеи появляются и мутируют с регулярностью и резвостью эпидемий гриппа.
С другой стороны, если позвонить, например, в Альфа-банк, можно поговорить с роботом, который сперва уговорит тебя не просить перевести на оператора, потом распознает не самый простой вопрос и выдаст нужную информацию без “подождите пару минут на линии”. Хорошо ли это, или плохо — кто знает. Но очевидно, что начинающие банковские служащие лишаются пула “детских” рабочих мест, и не проходят через горнило реальной практики работы с капризными и часто невежливыми клиентами.
Интересно, а понимают ли, например, бухгалтеры, что их не заменяют роботами только потому, что сшить уголовное дело можно только на человека? И понимают ли коллеги из кофе-рума, что беспилотные автомобильчики — это просто очередной шаг к беспилотным средствам разработки программных продуктов?
Если подумать, SkyNet окажется не такой уж и оголтелой фантастикой.
