Проблемы современной разработки. Часть 3:  Понимание

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

Читайте и просвящайтесь, вообщем.

Части: первая, вторая, четвертая.

Гордость и предубеждение

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

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

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

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

В ход идет игра на нервах, профессиональной гордости, меркантильности — вообщем абсолютно все средства хороши чтобы заставить очередного ит-задрота выйти поработать в выходной.

Так это работает в большинстве проектов и в большинстве компаний.

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

Если одни считают себя хищниками, а другие — жертвой, о каком таком понимании вообще может идти речь?

Партнерство между менеджерами и инженерами?

Забудьте, это не работает даже в Европе и США, не говоря уже о нашей окраине.

«Hacker & Hustler» — миф, красивая распиаренная сказка, для отлова наивных айтишников в «партнерские отношения с минимальной зарплатой».

Осознание

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

Поэтому в вашем случае (надеюсь) до взорванного ядерного реактора дело не дойдет.

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

Вообщем у вас уже сложилось осознанное понимание что ваших программистов надо все же иногда слушать, даже если они порят одну сплошную чушь.

Вот теперь давайте разберем как это сделать, начнем с типичных заходов.

Есть проблема

Самый лаконичный заход.

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

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

Вообщем что-то такое, подпадающее под термин «полный п#здец».

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

Либо ноль либо единица ага.

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

Это невозможно

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

Яркий пример для иллюстрации:

Машина ведь едет? — Едет.

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

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

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

Может быть так, что последствия принятых в спешке решений придется разгребать десятки лет — legacy называется.

Мы не укладываемся в сроки

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

Радуйтесь вообщем, что они сами вам говорят, благо обычно все происходит ровно наоборот:

Через пару месяцев, работа еще в самом разгаре, а Вася задумчиво чешет репу и сообщает что «немного ошибся».

Тем не менее, вы должны понимать что:

Его не было ни в 70х, в условиях перфокарт и мейнфреймов, ни в 80х, ни в 90х и уж тем более не может быть сейчас — в век сетей, онлайн-сервисов и всякой такой распределенной х#иты.

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

А коль нет способа оценки, очевидно что вам не смогут называть реальные сроки. И чем больше проект или требуемый функционал — тем менее и менее реальнее будут сроки.

Соответственно вам придется вычислять самому.

Идеальный вариант — ориентироваться на предыдущий результат:

Если команда и проект — стабильные, то вообщем-то сильных отклонений не будет.

Если же программистов (уже) нет, либо сам проект развален - нужна независимая оценка сторонней командой.

Чаще всего это делается банальным обращением к компании-аутсорсеру — за небольшой прайс они с радостью проведут аудит, все опишут и оценят примерный объем работ.

Я и сам смогу помочь с подобной оценкой — пишите.

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

Почему не работает

Мое любимое.

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

Простой и лаконичный ответ: потому что сломалось.

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

Недели так две.

Да и читать потом 50-страничный талмуд с картинками и мелким текстом вы ведь все равно не будете, зачем?

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

Тратить время когда что-то сломалось стоит на починку а не на глупые вопросы.

Когда почините

Второй по типичности вопрос, вытекающий из первого.

На него также есть не менее лаконичный ответ: как только так сразу.

Дело в том что нет адекватного и мгновенного ответа на этот вопрос — потому что нет простого способа быстрой оценки масштаба поломки и возможного ущерба.

Даже если есть SLA, есть прописанные инструкции действий и бекапы — вам все равно будут называть сроки из головы.

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

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

Почему сразу такое «или-или»?

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

Поэтому имеем дело со стадией «колхозный стартап» и разбираемся с конректным сервером.

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

В решении проблемы это не поможет.

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

Затем логи системы и обновления — обновление системных библиотек ломает приложения использующие fork-join или запуск новых процессов в работе «на раз-два».

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

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

Поэтому что в банке, что в стартапе, что в Гугле с Амазоном что в мелкой ИТ-компании — сбой всегда непредсказуем.

И ответ абсолютно всегда: починим когда починим.

Когда все будет готово

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

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

Не надо так делать, никогда.

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

Еще вам надо знать что нормальный программист проходит несколько стадий при написании кода:

1. Черновой вариант, прототип — доказательство что логика работает, без оптимизаций, без форматирования и комментариев;
2. Финальный вариант — вычещенный код, с форматированием и комментариями;
3. Тестирование и доработки — могут быть добавлены отдельные ветки логики для каких-то специальных вариантов поведения и входных условий.

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

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

Как обычно печальные выводы

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

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

В этом случае - да, думаю мои статьи помогут не прикончить всех сразу.

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

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