Всем привет!
🤟 Сегодня в гостях у OTUS Дмитрий Панкрашов — Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev и преподаватель курса “Python Developer. Professional” в IT в OTUS.
Дмитрий поделился личным опытом проектирования и внедрения системы автоматизации без четкого ТЗ и менторской поддержки, с какими ошибками он столкнулся в процессе и какие выводы сделал.
Обычно дети думают, что знают всё лучше родителей, а начинающие разработчики в этом смысле чем‑то похожи на детей. Они всегда всё знают лучше, чем их старшие коллеги. Но иногда бывает так, что джун на первой работе получает задачу спроектировать и реализовать систему целиком, и тогда его уверенность в том, что он точно знает, как и что надо делать, укрепляется, потому что он‑то сделал систему, а остальные только и могут рассказывать, что «хорошо делать хорошо, а плохо делать — плохо».
Когда‑то и я таким был. Устроившись на должность разработчика к подведу местного МинОбра (образования, не обороны!), мне поручили реализовать и внедрить в работу систему, рассчитанную на массовое использование. Система предназначалась для автоматизации процесса аттестации педагогических работников. Сотрудники школ, детских садов и других организаций могут подать заявление на присвоение категории, которая дает некоторую прибавку к зарплате. Заявление сопровождается отправкой портфолио, содержащим подтверждающие документы. Портфолио рассматривают эксперты, по результатам принимается решение о присвоении, либо отказе в присвоении категории.
Процесс, как водится, был «в бумаге» и требовалось перенести его и все данные «в компьютер». Технических заданий, дизайн‑документов, UML‑диаграмм, и прочего аналитического добра у меня, конечно же, не было. Были только утвержденные формы портфолио, и объяснения, как оно работает «на пальцах».
Как вы понимаете, этот текст не об успешном успехе и результатах внедрения, превосходящих все самые смелые ожидания, а о допущенных ошибках.
Ошибки — важная часть процесса обучения. Можно заучить «как правильно», и не понимать, почему же правильно именно так, а не по‑другому. А может, «правильно» делать надо не во всех случаях? А где можно срезать углы, и чем это черевато?
Как вы понимаете, ошибок, допущенных мною, было много. Какие‑то были чисто техническими, какие‑то связаны с коммуникацией. Что‑то всплывало сразу, что‑то удалось увидеть и понять значительно позже. Несмотря на то, что проект живет, он мог бы быть лучше. В общем смысле все ошибки можно разделить на ошибки проектирования, ошибки реализации, ошибки выстраивания коммуникации.
Ошибки проектирования
Все слышали поговорку «Семь раз отмерь — один раз отрежь»? Она в том числе и про проектирование.
Ошибка 1️⃣- Не проектировать вообще.
Максимум, что было у меня в голове после изучения бумажной формы портфолио — примерная концепция пользовательского интерфейса с деревом папок‑критериев оценки. На тот момент я мог еще нарисовать диаграмму потоков данных (по сути, схему базы данных, с таблицами и отношениями между ними), но, как я посчитал, без этого можно обойтись. Да и вообще, что там программировать?!
Ошибка 2️⃣-Проектировать только техническое решение.
Как показала практика, учитывать взаимодействие «пользователь — сотрудник — проверяющий», особенно, если оно может происходить в обход системы, все же нужно. Хотя бы для планирования возможных «дырок в заборе».
Ошибка 3️⃣- Я вообще‑то разработчик, а не эти ваши…
Любой разработчик минимально тестирует то, что пишет. Но «протыкал кнопки по предполагаемому user‑flow» и реальное использование — разные вещи, как выяснилось позже.
Спустя время кажется, что при отсутствии внятного ТЗ и желания его писать, можно было на неделю погрузиться в будни сотрудников, работающих по автоматизируемым процессам. Тем более, что после разработки всплыли дополнительные «хотелки», не учтенные изначально, и работа стала напоминать на строительство рельс перед несущимся паровозом.
➡️ В следующем посте поговорим про технические ошибки.
#expert
