Я математик по образованию, но, очень долго работаю в софте на разных должностях и в разных ролях. За долгую карьеру, накопилось множество интересных случаев, из которых каждый может сделать для себя разные выводы.
Однажды, тёплым, майским утром, ко мне пришёл PDM с предложением проекта, от которого невозможно было отказаться - аффилированная компания, которой, обычно отдавали такие работы, была занята до конца года, а в начале лета, требовалось провести процедуру Performance Review в большом подразделении нашей компании.
Требования были выданы "на словах" и они были ОЧЕНЬ нереальными:
авторизация через LDAP
возможность авторизовать "сторонних" участников ревью (из смежников, или подрядных компаний)
доменное имя первого уровня в компании
3 недели срока
Пришлось огорчить, на дворе стоял 2022 год, Имперская Безопасность - лютовала, так, что простое получение, обозначенного, доменного имени, заняло бы более месяца, с обоснованиями и согласованиями,... да и "сторонние" участники, внутри контура компании, для авторизации LDAP, выглядели, просто, бельмом на глазу.
PDM погрустнел,... но, как в сказке, я предложил ему заглянуть утром: "утро вечера мудренее". А пока, озадачил свою команду небольшой идеей. Были, кое-какие намётки, а как говорил мой учитель физики: "каждый экспромт, должен быть хорошо отрепетированным". До вечера немного поин��естигировали, помитинговали, поштурмили, и к утру, экспромт был готов.
Встретившись с PDM я погрузил его в идею: мы пишем ПОЧТОВОГО РОБОТА, который будет рассылать сгенерированные экселевские файлики, где разрешено менять только некоторые поля.
Эта архитектура закрывала все пункты исходных требований:
почта решала вопросы с авторизацией пользователя
"сторонние" участники, естественно, имели почту и вопрос с их подключением внутрь контура - отпадал
доменное имя - не нужно, так как веб морды у сервиса нет вообще
3 недели - вполне реалистичный срок, что бы наваять этот сервис на питоне
Получив ДОБРО, мы засели за проектирование небольшой БД, что бы хранить результаты и набора команд, на которые будет откликаться сервис.
Идея очень простая и состоит из нескольких шагов:
подготовка структуры подразделения
первоначальная рассылка где каждый участник описывает свои достижения и выбирает ревьюверов
в соответствии с этим списком, происходит формирование писем ревьюверам, для запроса обратной связи
подготовка и отправка обратной связи
поведение результатов
Набор команд был сформирован для администрирования сервиса:
прислать текущий граф иерархии участников ревью
посмотреть, кто не подготовил описания с запросом обратной связи, в рамках первоначальной подготовки и отправить напоминания им и их руководителям
закрыть первый этап и провести проверку
разослать письма для ревьюверов в рамках второго этапа
проверить, от кого не пришло откликов и направить напоминание
закрыть второй этап и сформировать результирующую оценку
Получив от ассистента руководителя список участников с проставленными руководителями для каждого, мы смогли построить граф подразделения,... правда, уже в первой же попытке нашли ошибки во входящей информации, из-за чего граф оказался кривым. Пришлось встраивать проверки на адекватность графа:
отсутствие циклов
отсутствие отдельных (висячих) элементов
Первоначальный этап, в результате выглядел так:
формируется дерево подразделения, на основе входящего списка
для каждого участника, формируется Excel файл (использовали openpyxl)
с использованием служебного аккаунта на MS Exchange генерировали письмо, с вложенным файлом с прошлого шага (использовали exchangelib) и отправляли его участнику
Далее, каждый участник заносит свои проекты в сгенерированную форму, за последние полгода (не более трёх), свою роль в каждом из них и ревьюверов с их email адресами, для отправки запроса на отзыв и когда файл готов - отправляет его обратно на служебный ящик.
Робот, видя, от кого он получил письмо, парсил его, и в случае ошибки - отвечал обратно коротким сообщением об ошибке, если же парсинг прошёл нормально, заносил результаты в БД и отвечал, что запрос на ревью - принят.
За неделю до начала активной фазы ревью, то есть, когда ревьюверам свалятся письма, с просьбой об обратной связи, мы договорились испытать команду роботу, на проверку полноты запросов на обратную связь. Конечно же многие откладывали эту работу до последнего, поэтому напоминалки работникам и их руководителям на почту, уходили в больших количествах.
Но, закрылись в первый раз, с небольшим опозданием,... пришлось подождать кого-то из отпускников
Далее, всё по плану - для ревьюверов были сгенерированы экселевские файлы, уже по другому шаблону и они ушли исходящими письмами.
Мы сели обрабатывать первые проблемы:
опечатки в фамилиях или email адресах, из-за чего кто-то задваивался, или письма уходили в никуда,... естественно, с ошибками - добавили обработку некорректных адресов
кто-то был в отпуске и у него был установлен ООО,... что воспринималось, как неверный ответ, о чём шла нотификация, на которую опять приходил ООО,... (что бы понять рекурсию, нужно понять рекурсию)
Из-за сжатых сроков, не было ни нормального анализа, ни полноценных требований,... это был чистый AGILE,... мы творили на лету, непосредственно работая с пользователями нашего сервиса.
Когда ошибки поправили, что-то перегенеряв, что-то перезапустив вручную - мы стали ждать третьего этапа - прихода обратной связи и обработки результатов.
Вот тут, учитывая, два предыдущих этапа, всё было уже скучно...
И, хотя, PDM подгонял нас и просил сделать: "хоть как-нибудь, ведь это же на один раз", моя установка команде была: "делать, как для себя"... Поэтому я не удивился, ни тому, что в ноябре пришло немного новых требований на развитие сервиса, ни тому, что он жив и развивается до сих пор, а прошло уже больше 8 ревью.
