Вы когда-нибудь задумывались, почему программисты, несмотря на вечные дедлайны, кривые ТЗ и клиентов, которые «просто хотят добавить одну маленькую кнопку», до сих пор не сбежали в леса разводить кроликов? Ответ прост: без чувства юмора в нашем мире не выжить. А еще — потому что реальные истории из жизни разработчиков смешнее любого скрипта от Саша Бена.
Сегодня я поделюсь двумя случаями из своей практики, которые, если их подать как сценарий для сериала, вызовут у продюсеров смех сквозь слезы. Это истории про клиентов, которые исчезают, как Мерседес в тумане, и госпроекты, где главный фичей оказалась имитация работы. И да, все это — не вымысел, а чистая правда, проверенная бессонными ночами и синяками под глазами.
1. Сетевой маркетинг: Когда клиент превратился из Мерседеса в автобус (и почему математика спасает от пирамид)
Представьте: 2012 год, эпоха, когда «сетевой маркетинг» звучал как синоним «быстрого обогащения», а законы о нем были мягче пластилина. Ко мне и техническому директору приходит клиент с горящими глазами и требованием: «Сделайте так, чтобы люди сами себя обманывали! Ну, или почти сами».
Что хотели клиенты?
Классическая пирамида: новый участник платит 1000$, приглашает двух друзей, те платят еще 1000$, и так далее. Но проблема была в том, что в 2012 году такие схемы уже начали прикрывать как мошенничество. Клиент, однако, настаивал: «Да ладно, вы же программисты! Сделайте так, чтобы это выглядело легально!».
Мы, конечно, попытались объяснить, что «легально» в этом случае — это как «безалкогольный джин» — звучит абсурдно. Но клиент был настойчив: «Ну сделайте же что-нибудь! Я же на Мерседесе приехал!».
Как мы «смягчали» пирамиду
После недели споров (и пары бутылок виски для храбрости) мы придумали «легальную» версию:
- Убрали прямую привязку к деньгам: вместо оплаты за приглашения ввели «бонусные баллы».
- Добавили сложную математику: чтобы заработать, нужно было не просто зазывать людей, а выполнять квесты (например, «прочитай 5 статей о здоровом образе жизни»).
- Внедрили систему «рангов»: чем больше активности, тем выше статус, но реальные выплаты — только за продажу реальных товаров (которых, конечно, не существовало).
Клиент был в восторге.
Но тут началось самое интересное
Через месяц после старта проекта клиент пропал. Просто исчез. Никаких звонков, писем, даже тени Мерседеса у офиса. Мы с техдиром сидели в офисе, смотрели на незавершенный дизайн и думали: «Ну и зачем мы это делали?».
Через два месяца он объявился. Но Мерседеса не было видно.
— Где результат?! — заорал он, ввалившись в офис. — Я же заплатил!
— Вы пропали на два месяца, — спокойно ответил техдир. — Мы ждали утверждения ТЗ по дизайну.
— Да мне пофиг на дизайн! Мне нужны деньги! — орал клиент. — Вы что, не могли просто сделать?
Тут мы поняли из-за шаблона поведения: клиента кинули. Потом выяснилось что его партнеры слили бюджет, и теперь он хотел забрать наш код бесплатно, чтобы «реанимировать проект». Но самое смешное было в том, что он сам стал жертвой той самой пирамиды, которую пытался запустить. И да, когда он ушел из нашего офиса, я тоже пошел купить еду в магазине и заметил нашего клиента на автобусной остановке, вот так мерседес и трансформировался в автобус, досих пор вспоминаем эту историю и смеемся.
С тех пор у нас появился внутренний мем: «Если клиент пропал — проверьте автобусные остановки».
2. Госпроект: Как я полюбил спагетти (и научился любить C# сквозь слезы)
Перейдем к истории, которая точно попала бы в список «Топ-10 самых странных госзаказов».
Что было не так с этим проектом?
Компания выиграла тендер на разработку системы для госучреждения. Система:
- Написана на C# 3.0 (да, это как использовать Windows 95 в 2023 году).
- База данных — 500 ГБ медленного MSSQL (весом, как совесть чиновника после отчета).
- Кодовая база — лапша из goto, копипасты и комментариев в стиле «тут что-то должно работать».
И самое смешное: я был единственным, кто знал C#. При этом я пришел в компанию как Python-разработчик. Как так вышло?
— Руководитель: «Ну, хорошо что ты знаком с C#, а то уж незнал как этот проект делать!».
— Я: «Но я же Python-разработчик…».
— Руководитель: «Ой да ладно тебе, всё во благо мира во всем мире, пострадай немного!».
Три месяца ада: как я пытался не умереть от оптимизации
Моя задача: добавить новый функционал + ускорить систему. Срок — 3 месяца.
Первый день:
— Запускаю проект.
— Система грузится 47 минут.
— В логах: «Error: OutOfMemoryException (но это не точно)».
Второй день:
— Нахожу метод с названием DoMagic(), который делает 17 вложенных запросов к БД.
— В комментарии: «Этот кусок кода — как мой брак: никто не понимает, как он работает, но все боятся трогать».
Третий день:
— Пытаюсь объяснить заказчику, что «просто добавить кнопку» невозможно, потому что вся система завязана на stored procedure из 2005 года.
— Заказчик: «А в чем проблема? В Excel же все работает!».
Как я выжил (и что такое «имитация работы»)
К концу третьего месяца я был похож на зомби: синяки под глазами, руки дрожат от кофеина, а в голове крутилась только одна мысль: «Почему я не стал бухгалтером?».
За неделю до демонстрации мой директор сказал:
— Слушай, есть идея. Некоторые фичи не готовы. Просто сделай так, чтобы они выглядели работающими.
— Как? — спросил я, уже не удивляясь.
— Ну, нажал на кнопку — появилось окно «В разработке». Или анимация крутится. Главное — чтобы они поверили, что это работает.
Я добавил:
- Фейковый прогресс-бар, который «загружал» данные 10 секунд (на самом деле — заглушка).
- Кнопку «Экспорт в PDF», которая открывала PDF с надписью «Скоро будет!».
- В разделе отчетов — график с рандомными числами и подписью «Тренд роста».
Демонстрация: три часа пустоты
Пришли трое чиновников. Один смотрел в телефон, второй зевал, третий спросил:
— А можно тут… ну, как в Excel?
Я нажал на фейковую кнопку. Заказчик одобрительно кивнул.
— Отлично! А когда будет полная версия?
— Через месяц, — соврал я.
После демонстрации директор похлопал меня по плечу:
— Молодец! Они же даже не заметили, что половина фич — заглушки.
Вечером я написал в Slack:
«Госзаказ — это когда платят за то, чтобы ты умел делать "имитацию" в интерфейсе. Следующий этап — научить код генерировать отчеты в стиле „Тренд роста“».
3. Почему программисты шутят над всем этим? Или как не сойти с ума в IT
Вы наверняка задаетесь вопросом: «Зачем вообще писать про это? Не лучше ли забыть и двигаться дальше?».
Да, можно. Но шутки — это наш щит от абсурда.
Почему юмор важен в работе программиста?
- Клиенты не всегда понимают, что они хотят.
— «Сделайте как у Facebook, но только лучше и бесплатно».
— «А можно, чтобы кнопка моргала, но не раздражала?».
Шутка: «Клиент — это как ребенок: хочет все и сразу, но не знает, что такое deadline». - Госпроекты — это отдельная вселенная.
— Требования меняются каждую неделю.
— Документация написана в 2007 году, а проект запускается в 2023.
Шутка: «Госзаказ — это когда ты пишешь код для будущего, но на технологии прошлого, а оплачивают его из бюджета будущего». - Код иногда становится личностью.
— «Этот баг живет дольше, чем мой последний relationship».
— «Мой код — как моя жизнь: кажется, что все работает, но на самом деле это хрупкий баланс».
Как сохранять чувство юмора?
- Создавайте внутренние мемы. Например, у нас в команде есть «Клиент-автобус» — метафора для всех, кто исчезает и возвращается с новыми требованиями.
- Не бойтесь шутить с заказчиками. Иногда фраза «Этот баг — часть философии проекта» снимает напряжение.
- Пишите в чаты глупые коммит-месседжи. Например: «fixed the bug that wasn’t there (but now it is)».
4. Советы программистам: Как не стать героем чужой шутки
Если вы только начинаете в IT, вот несколько правил, которые спасут вас от историй вроде моих:
Правило 1: Не верьте клиентам, которые приезжают на Мерседесе
Если клиент хвастается бюджетом, но не может четко описать ТЗ — это красный флаг. Спросите:
— «Какой KPI у этого проекта?».
— «Что будет, если мы не уложимся в срок?».
Если ответ: «Да ладно, это же просто кнопка!» — бегите.
Правило 2: Госпроекты = терпение + умение врать
- Требуйте четкого ТЗ еще на этапе тендера.
- Добавляйте в договор пункт: «Изменения требований после утверждения ТЗ оплачиваются отдельно».
- Учитесь говорить: «Это технически невозможно», даже если это не так.
Правило 3: Юмор — ваш главный инструмент
Когда коллега ломает продакшен:
— Не кричите. Скажите: «Отлично! Теперь у нас есть повод для нового мема».
Когда клиент хочет «одну маленькую правку»:
— Ответьте: «Конечно! Это займет… ну, примерно как полет на Марс».
Заключение: Почему IT — это не про код, а про людей
Эти истории — не просто смешные случаи. Они показывают, что программирование — это не только логика и алгоритмы, но и умение работать с людьми.
Клиенты будут исчезать, проекты — гореть, а код — превращаться в лапшу. Но пока мы можем посмеяться над этим, мы не проиграем.
Так что в следующий раз, когда заказчик скажет: «Это же просто!», просто улыбнитесь и ответьте:
«Конечно! Как только вы объясните, как сделать вечный двигатель, я добавлю вашу кнопку».
А если вдруг увидите клиента на автобусной остановке — знайте: это не конец истории. Это только начало новой шутки.
P.S. Если вы дочитали до конца — вы герой. Поделитесь в комментариях своей самой странной историей из IT. А еще поставьте лайк, чтобы боты Дзена не думали, что программисты не умеют шутить. 😉
P.P.S. Клиент из первой истории до сих пор иногда звонит. Теперь он продает криптовалюту. Сюрприз? Нет.