С завтрашнего дня начинаем жить по-новому. Будет у нас Скрам и будет счастье. Полная демократия: никаких начальников, команда сама решает, что ей делать, бюрократия отменяется, главное – сделать заказчику хорошо.
Приезжал тренер, обучал нас основам. Рассказывал про неминуемый успех, про эффективность и клиентоориентированность, про небывалую гибкость и важность вовлечения клиента в процесс разработки, и про космические корабли, бороздящие Большой театр.
Ну-ну. Поживём-увидим.
Начинаем новый проект. Ну, слава богу!
А то я уже мхом покрылся от сидения над легаси кодом. Сил моих больше нет, не могу я совладать с этим великим макаронным монстром. Я вон как-то попробовал передвинуть кнопку в форме входа, так у меня ошибки из почтового модуля посыпались. Вот и думай, где тут связь…
Познакомили нас с новым сотрудником, будет у нас Product Owner или, по-русски говоря, представитель заказчика. Зовут Рита. Обаятельная женщина. Очень любит поговорить.
Задашь ей простой вопрос, так она заводит спич на полчаса. Смотришь на неё и думаешь: “Э, да ты ж не понимаешь ни черта!”.
Через пять минут сомневаться начинаешь: “Да нет, вроде дело говорит”.
В конце осознаёшь, что так и не получил ответа на свой вопрос. Так и уходишь.
Главное, прервать её нет никакой возможности. Пытаешься вклиниться и направить словесный поток в нужное русло, но где там, она знай себе заливается и рассказывает опять же про корабли и Большой театр.
Мы уж бояться стали задавать ей даже простые вопросы. Можешь получить ответ, а можешь утонуть в словесном океане.
Да, бюрократии и впрямь стало меньше. Потому что все забили на документирование вообще. Теперь информация передаётся в основном из уст в уста. Я, конечно, всё понимаю, мы очень даже agile, но не до такой же степени…
Дали задачу: разработать в шлюзе возможность получения клиентом данных для отображения графика. Надо обратиться к сервису, получить сырые данные, пересчитать их и отдать клиенту. Спецификации никакой нет, что и как считать – никто не знает. Есть только название графика. Ну и как я должен это делать, интересно?
Ладно, разыскал где-то в наших старых проектах нечто подобное, сделал по образцу. Никакой уверенности, что это то, что нужно, нет. Странно, но никого это особо не волнует. Главное, что мы успешно представили новую функциональность на демо-митинге.
Прихожу сегодня на работу, там девушки-тестировщицы обступили нашего скрам-мастера Колю, и требуют объяснить им, как работает новая функциональность. Коля смотрит оловянными глазами в монитор и бубнит что-то про модели и про изменение требований.
Колю понять можно: что-то меняли месяц назад, а что именно, вспомнить трудно, документации-то нет. Но и девушкам не сахар: им поручили тестировать то, не знаю что.
Встретил их в коридоре через полчаса: вышагивает Коля, за ним девушки, и все галдят: “Новая модель… старая модель… требования клиента…”.
Бедные…
Получил пулл реквест на ревью. Ошибка в экспорте графика: пропорции высоты и ширины отличаются от оригинала. Странно, ведь я уже когда-то решал эту проблему и позаботился обо всех пропорциях… Решена проблема была оригинально: коллега просто умножил высоту на 1.25.
Спрашиваю его:
– Что этот коэффициент означает?
– А это, – говорит, – я подобрал. Теперь всё хорошо будет.
Во как! Подобрал он… А что же будет с экспортом других чартов? Стали разбираться, оказалось, что надо просто слегка поменять последовательность вызовов. В каких-то очень редких случаях используются свои установки для канваса, и надо пересчитывать пропорции после этого.
Возникает впечатление, что порой людям важно любыми средствами отчитаться о проделанной работе, а конечный результат их не особо волнует…
Сегодня Рита сообщила, что приняла решение использовать бесконечный скроллинг при отображении списка документов. Пытался убедить её, что ситуация в REST-сервисе постоянно меняется: одни пользователи добавляют документы, другие удаляют. В результате, в форме либо будут появляться лишние элементы, либо они будут пропадать, поэтому лучше использовать старую добрую паджинацию. На что мне было отвечено, что такая ситуация редка, а бесконечный скроллинг – это модно и сексуально, пользователи будут довольны.
Довольны? Хм… Я бы расстроился, если бы обнаружил, что список не соответствует текущему состоянию…
Не понимаю, как можно строить здание из говна и палок, без фундамента, начиная при этом сразу с четырёх углов одновременно. Порой я думаю, что если бы самолёты, пароходы и небоскрёбы проектировались так же, как современный софт, то самолёты сразу же попадали, суда перевернулись вверх дном, а наши города лежали бы в руинах. Понятно, что у нас цена ошибки гораздо меньше. В конце концов, не медицинский или космический софт создаём. Но софт наш сложен, использует множество микросервисов. Надо же обращать какое-то внимание на предварительную проработку деталей!
Хорошо, что мы самолёты не конструируем…
Заглянул в соседний отдел и с порога почувствовал, что что-то не так. Все сидят, бешено стучат по клавиатурам, а в воздухе висит какое-то ощущение общей беды.
Вдруг их скрам-мастер Витя подскакивает и как закричит кому-то:
– Что ты мне всё пишешь! Скажи орально!
И тут их прорвало. Все сразу загалдели. Орально. Шум поднялся необычайный.
Я постоял минуту, кашлянул, все замолчали и уставились на меня. Мне вдруг стало как-то неуютно.
Витя говорит:
– Ты авторизацию в сервисе менял?
– Да, – отвечаю, – менял. Теперь пользователи без прав не могут читать ресурс. Надо другой путь использовать.
– Вот ты поменял, – говорит, – а у нас теперь приложение перестало работать.
Помолчал немного и добавил:
– Ты всё правильно сделал, это наш косяк. Но нам, понимаешь, надо релиз через три часа выкатывать, а ошибку мы не можем так быстро исправить.
Хотел я им сказать: “Что ж вы, черти, тесты-то ни разу не запустили, ведь неделя уже прошла!”, но посмотрел на их лица, развернулся и пошёл делать откат в сервисе.
Собрал нас сегодня главный и говорит:
– Надо бы эпик завести. Хотим машинное обучение ввести для настройки результатов поиска.
Народ, понятное дело, интересуется, что имеется в виду и есть ли описание проблемы.
– Полного описания нет ещё, я вам кину ссылки, на то что есть. Подумайте пока, – отвечает. И ушёл.
Посмотрел я потом страничку по его ссылке: заголовок и два пункта. И как думать прикажете, если непонятно, над чем думать?
Что же с ними происходит, ведь технические люди были, из простых разработчиков поднялись, а теперь вот как будто в клиентов переродились. Услышал где-то, что искусственный интеллект – это модно и круто, и давай эпики заводить. Ни задание конкретизировать, ни спецификацию точную написать, всё сплошь высокие материи да космические корабли с театрами…
Встречаю сегодня Витю в коридоре и спрашиваю:
– Ну как, ошибку-то нашли? Месяц уже прошёл. Надо бы в сервисе восстановить авторизацию, а то живём с дырой.
Витя взгляд отводит и говорит:
– Не, не нашли пока. Времени совсем не хватает…
Ну вот вам и пожалуйста. Месяц люди не могут найти место, где не тот эндпоинт используется. Судя по всему, они уже забросили это и занимаются текущими делами. Странно, ведь программа, по сути, использует неверные данные…
Да, вот и наш новый шлюз превратился в тугой клубок макарон, и концов найти уже невозможно. Быстро же мы управились!
Пытаюсь убедить коллег поговорить с начальством по поводу нынешнего состояния дел. С моей точки зрения, проект находится в плачевном состоянии: разные команды, решая свои задачи, вносят правки, увеличивающие хаос, энтропия растёт. С каждым разом решение задач становится всё более и более сложным.
Ребята со мной согласны, но к моим инициативам относятся прохладно. И их можно понять: у каждого есть текущие задачи, которые обязательно надо решить в течение спринта. Тут не до философствований, дело надо делать…
Признаюсь: я выдумал этот дневник. Все персонажи вымышлены, совпадения случайны. Это всего лишь шутка.
Бывает порой, что менеджмент воспринимает Agile несколько вульгарно: достаточно слегка обрисовать задачу, и хорошая команда разберётся со всеми архитектурными и концептуальными проблемами сама. Часто забывают и о необходимости тщательного документирования, хотя использование Agile вовсе не означает отказ от документации.
Однако, я хотел поговорить не об Agile и не о технологиях разработки. Я хочу порассуждать о качестве софта, который мы с вами создаём, и о том, как плохие решения могут разрушать этот софт.
Конфликт интересов
Вы – разработчик. Проект или часть проекта, над которыми вы работаете – это ваш любимый ребёнок. Вы создаёте и пестуете его, вы хотите, чтобы у вас получилось совершенное творение. Чтобы ваши коллеги и пользователи могли сказать: «Да, это классная вещь!».
Но вы работаете на бизнес, который вас нанял. Бизнес не интересуют ваши амбиции. Главная цель бизнеса – это прибыль, и это правильно. Тут вы с бизнесом заодно, ведь вы же хотите, чтобы вашим проектом пользовалось как можно больше людей?
Но в силу тех или иных причин, бизнес может принимать решения, которые нарушают гармонию вашего проекта. Скажем, надо очень быстро подкрутить что-то, а то клиент уйдёт. Нет времени решать задачу правильно.
Что же делать?
Скорее всего, придётся переломить себя, уповая на то, что нынешние костыли удастся убрать впоследствии…
Впрочем, не всё так печально. В долгосрочной перспективе – бизнес ваш союзник в борьбе за качество, если он, конечно, не враг себе.
Хотя, приходилось встречаться и с таким подходом, что тщательной проработкой деталей и анализом можно иногда пренебречь, поскольку быстрое и дешёвое удовлетворение пожеланий клиентов важнее всего. Возможен ли успех в таком случае?
Возможен ли успех?
Парадокс заключается в том, что такие продукты вполне могут быть коммерчески успешными, по крайней мере на первом этапе. Клиентов, конечно, раздражают многие недостатки и несообразности в системе, но, в целом, продукт решает их задачи.
Клиенты довольны уровнем поддержки: к их нуждам относятся внимательно и стараются быстро удовлетворить новые потребности. Правда, некоторые из них со временем замечают, что система становится всё более противоречивой и непредсказуемой в поведении, интерфейс усложняется, всё труднее становится понять, что происходит внутри, как надо правильно решать ту или иную задачу, появляются проблемы со временем отклика и так далее. Но это происходит постепенно и на первых порах незаметно.
Никто пока не подозревает, что проект обречён. Скоро он неминуемо рухнет от тяжести всех прилепленных к нему на скорую руку пристроек.
Насколько связана внутренняя стройность продукта с его потребительскими качествами? Часто бывает так, что разработчики находятся в состоянии перманентного ужаса от внутреннего состояния системы, а клиенты при этом вроде бы удовлетворены. Но может ли некрасивый самолёт быть хорошим? И не должна ли внутренняя гармония продукта отражаться на его потребительских качествах?
Не секрет, что часто за красивым фасадом скрываются непотребные внутренности, и касается это не только маленьких фирм, но и гигантов софтверной индустрии. Вот лишь один пример.
Компании-монстры могут позволить себе нанять тысячи программистов, чтобы поддерживать гигантское блюдо спагетти, в которое за годы и десятилетия превратился их продукт, но для мелких компаний это убийственный путь. И, кстати, даже для монстров низкое качество кода не проходит бесследно и оборачивается экспоненциально увеличивающимся временем разработки и внедрения каждой новой фичи, удорожанием процесса и постоянно снижающимся качеством поддержки.
Что важнее: качество продукта или умение продавать?
Качественный продукт, увы, не является залогом успеха.
Был у меня случай в практике, когда одну узкоспециализированную программу, неплохо зарекомендовавшую себя в России, надо было продвинуть на европейский рынок. Программа использовала свой формат данных, и конвертация имеющихся на тот момент данных клиентов не представляла особой трудности. Если бы нам удалось заключить контракты, мы бы стали на какое-то время монополистами в Европе. Казалось бы, всё на нашей стороне: запрос на рынке большой, предложить что-то завершённое и реально работающее пока никто, кроме нас, не может, программа уже работает на сотнях рабочих мест в России, российские клиенты отзываются о продукте положительно.
И что же, добились мы успеха? Увы, нет. Тендер выиграла европейская компания, уже работавшая с клиентами по другим направлениям. Они в тот момент находились только в начале пути, уже пройденного нами, но сумели переиграть нас. У нас, к сожалению, не было хороших специалистов по продвижению и продажам, и мы не смогли убедить людей сделать выбор в пользу нашей компании. Потом, по прошествии некоторого времени, было очень обидно видеть наши наработки в организации пользовательского интерфейса в их новом продукте…
Плохие решения
Качественный продукт – это стратегическая цель, и умный бизнес всегда будет на стороне разработчика, стремящегося к совершенству. Но поддерживать внутреннюю гармонию продукта нелегко. С развитием продукта к нам приходят новые требования, которые могут разрушать изначальную стройность концепций. Решения, которые принимаются в таком случае, играют определяющую роль в дальнейшей судьбе продукта.
Никто не застрахован от плохих решений. Если стратегическое решение принято на этапе проектирования, и с течением времени становится ясно, что оно было неправильным, это приводит к гибели проекта. Но часто плохие решения принимаются во время развития, когда добавляется новая функциональность. Тут всё зависит, во-первых, от глобальности принятых решений, то есть степени их влияния на систему в целом, а во-вторых, от количества плохих решений. Когда количество плохих решений и степень их влияния превышает некоторый порог, начинается долгая и мучительная агония.
Хотел бы поделиться с вами несколькими примерами плохих решений из своего опыта. Разумеется, эти примеры ни в коем случае не претендуют на академическую широту и систематизированность.
Нестрогие правила
Порой нам кажется, что в целях удобства пользователя правила должны быть гибкими.
Например, ваша система работает с разными типами иерархий, создаваемых пользователями. Вы принимаете решение, что для одного из типов ключ узла является уникальным только в рамках уровня, а не во всей иерархии. Это кажется удобным, поскольку пользователь загружает иерархию уровнями.
Последствия: теперь программистам везде в коде придётся заботиться о подготовке составного ключа, и это часто будет приводить к ошибкам. Если пользователи имеют доступ к узлам по ключу, это тоже будет головной болью для них.
Возможно, стоит задуматься о более строгих правилах и требовать уникальности ключа во всей иерархии. Это пойдёт на пользу как разработчикам, так и пользователям.
Нарушение правил
У вас есть сложная иерархия объектов, создаваемых пользователем. Каждый объект содержит свойство Name, являющееся ключом, и Title с произвольным текстом. Для имени есть набор формальных правил, например, имя не должно содержать пробелов и специальных символов. В какой-то момент возникает задача автоматической генерации объектов одного типа из другого. Имя при этом должно строиться на основе Title и быть узнаваемым. Вы решаете нарушить правила и использовать Title в качестве имени: вам кажется, что это будет наиболее удобным для пользователей.
Приготовьтесь к проблемам в вашей системе, которые будут возникать в самых неожиданных местах.
Сложность настроек
Вы вводите установки, которые действуют только при определённых условиях. Когда одни установки действуют при условии, что включены другие, – это вполне обычная ситуация. Но если у вас имеется сложная иерархия установок, одни из которых действуют, когда включены другие, а те, в свою очередь, тоже являются условными, – это путь к хаосу. Опыт показывает, что в таком случае никто не готов предсказать, как повлияет изменение той или иной установки на поведение: ни пользователи, ни разработчики. Система настроек должна быть ясной, как можно более очевидной и тщательно продуманной. Следует стремиться к уменьшению зависимостей одних настроек от других.
Отсутствие анализа проблемы
Ваша система позволяет пользователю создавать отчёты на основе DSL. Решено вначале, что DSL содержит все свойства отчёта. По прошествии некоторого времени один из клиентов просит вас добавить возможность хранить часть установок отдельно – это нужно для решения каких-то внутренних проблем клиента. Заводить задачу в Jira «Add external settings» без предварительного анализа проблемы будет ошибкой. Прежде всего, надо ответить на вопрос: а зачем это вообще понадобилось? Вполне может оказаться, что клиент просто хочет скрыть часть установок для некоторых пользователей. Может быть, стоит задуматься о разбиении DSL на части с авторизацией этих частей? Решение не столь быстрое, но, возможно, стратегически верное.
Политические решения
Порой решения принимаются по организационным мотивам. Например, определённые ресурсы хранятся в специально предназначенном для этого микросервисе. Требуется добавить несколько подобных типов ресурсов. Сервисом занимается одна команда, а новые типы ресурсов нужны другим. Чтобы разделить ответственность, принимается решение добавлять новые типы не в исходный сервис, а в сервисы, которыми заведуют другие команды.
Проблема в том, что сервис не просто хранил данные, но и обеспечивал авторизацию. Теперь потребуется каким-то образом позаботиться о повторном использовании кода. Но не это главное. Главное – что теперь неочевидно, какой сервис следует использовать для получения нужных данных. Внутренняя очевидность построения системы принесена в жертву организационным или политическим мотивам.
Заключение
Как разработчик, я хочу гордиться результатами своего труда. Для меня важна внутренняя красота, изящность и стройность проекта. Но не менее важна и востребованность. Не хочется работать на корзину, хочется, чтобы как можно больше людей использовали продукт и были довольны. Я понимаю, что порой приходится идти на издержки и немного портить внутреннюю гармонию в угоду интересам отдельных клиентов. Но я убеждён в том, что за красивым фасадом не должно быть безобразия, уродливые внутренности рано или поздно полезут наружу, неважно, будет ли это внешняя сумятица в концепциях, или всё более увеличивающееся время реагирования на проблемы клиентов.
Красота и гармония продукта важнее всего. Да, мы порой вынуждены идти на компромиссы в интересах бизнеса и готовы к некоторому размыванию ясности подходов в интересах того или иного клиента, особенно если это очень важный клиент, но это скользкий путь.
Мне не раз приходилось наблюдать постепенное угасание и гибель проектов, когда люди не утруждали себя тщательной проработкой деталей и бездумно вводили новую функциональность, не заботясь о возникающих противоречиях в продукте и не обращая внимание на возникновение новых и ненужных связей между модулями. Это всегда приводит к неразберихе, когда становится всё труднее и труднее исправить самую простую ошибку, поскольку нет никакой уверенности, что это исправление не окажет неожиданного влияния на совершенно посторонние компоненты и части системы.
Хочу пожелать долгой жизни вашим проектам!
