Первый сложный проект: путевые листы и мусоровозы

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

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

Именно поэтому этот проект до сих пор для меня важен. Он довольно быстро выбил из головы иллюзию, что работа разработчика сводится к “написать код, чтобы он скомпилировался”. Вообще нифига подобного.

Главное

• Первый сложный проект редко сложен только кодом: обычно он сложен контекстом, ответственностью и отсутствием готовых ответов.
• Для меня эта задача стала входом не только в новую технологию, но и во взрослое отношение к разработке.
• Самый полезный навык, который появился тогда, это не знание конкретной платформенной особенности, а спокойное разбирательство в неизвестном.
• Именно такие проекты потом и становятся фундаментом карьерного роста, а не красивыми учебными примерами.

Почему этот проект оказался сложнее, чем я ожидал?

Потому что по описанию он выглядел как обычная доработка. В системе уже был основной функционал, нужно было обновить логику, поправить интерфейс и довести всё до рабочего состояния. На бумаге звучало терпимо. В реальности оказалось, что задача совпала с переходом 1С:Предприятия на управляемые формы, а это сильно меняло сам подход к разработке.

Часть логики уезжала на клиент, часть оставалась на сервере, поведение интерфейса становилось другим, а привычные паттерны уже не работали так, как раньше. Готового рецепта никто не держал в столе. Интернет на эту тему тогда тоже не радовал изобилием. То есть мне дали не просто “сложную задачу”, а задачу на стыке новой технологии, живого бизнес-процесса и общего командного поиска.

И вот здесь становится видно, насколько коварной бывает формулировка “небольшая доработка”. Она маленькая только до тех пор, пока не начинаешь разбирать, как всё связано.

Что именно в этой задаче меня больше всего качнуло?

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

Путевой лист для мусороуборочной машины не существует в вакууме. За ним стоит маршрут, порядок действий, ограничения процесса и ожидания конкретных людей, которые этой системой пользуются. Если ты в такой задаче понимаешь только форму документа, но не понимаешь процесс, решение получится хрупким. Оно вроде бы работает, но живёт до первой реальной нагрузки.

Для меня это был первый момент, когда я по-настоящему почувствовал: код без понимания контекста даёт ложное ощущение компетентности. Ты можешь сделать “как будто правильно”, и только потом выяснится, что ты не решил задачу, а просто красиво обернул непонимание в рабочий интерфейс.

Что мне реально помогло не утонуть?

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

Сейчас это звучит банально. Но на старте разница между “я не понимаю, значит я слабый” и “я не понимаю, значит надо идти разбирать по слоям” ощущается очень сильно. Именно на этом проекте я впервые начал не паниковать от неизвестности, а дробить её на части.

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

Потом этот способ работы очень пригодился и в других проектах, в том числе в более тяжёлых прикладных историях вроде 1С на ферме: Россельхоз и мемуары. Там уже была другая предметная область, другой масштаб, другие риски. Но базовая механика оставалась той же: сначала понять реальность задачи, а уже потом считать, что ты её решаешь.

Когда я впервые почувствовал ответственность разработчика?

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

Это очень отрезвляет. И, как по мне, довольно полезно отрезвляет. Ты перестаёшь думать о коде как о чём-то изолированном и начинаешь видеть его как часть системы, где у каждого решения есть хвост последствий.

Позже я уже отдельно писал про ответственность разработчика, но если честно, корни этого отношения у меня точно там. В первом проекте, где невозможно было спрятаться за формулировкой “я же только реализовал задачу”. Нет, ты не “только реализовал”. Ты встроил кусок логики в живой процесс. И это меняет внутреннюю оптику очень быстро.

Чему этот проект научил меня помимо технологии?

Самому важному. Экспертность редко приходит как ощущение “теперь я всё знаю”. Гораздо чаще она приходит как привычка спокойно заходить в хаос, не ждать мгновенной ясности и продолжать копать, пока структура не начнёт проявляться.

Если бы меня спросили, что именно дал мне этот проект, я бы ответил так: не знание конкретной платформенной особенности, а взрослое отношение к незнанию. Когда ты перестаёшь считать неизвестность провалом и начинаешь считать её нормальной частью профессии, ты растёшь намного быстрее.

Позже эта же логика помогала и в более широком профессиональном движении. Она же лежит под статьёй Критическое мышление программиста, где я писал, что ценность разработчика часто не в скорости ответа, а в качестве мышления под неопределённостью. Первый сложный проект был для меня очень ранней тренировкой именно этого качества.

Почему я до сих пор считаю этот опыт полезным для старта карьеры?

Потому что именно такие проекты быстро собирают из “человека, который учится программировать” специалиста, который начинает понимать вес своей работы. Не идеально, не сразу, не без ошибок. Но по-настоящему.

Есть соблазн думать, что для хорошего старта нужен аккуратный плавный вход, понятные задачи и комфортный рост сложности. Иногда это и правда работает. Но иногда именно неловкая, сложная, местами раздражающая задача даёт тебе больше, чем полгода красивых учебных примеров. Потому что она вынуждает не притворяться, будто ты уже всё понял.

И ещё она очень быстро учит правильно формулировать вопросы. Не “почему тут всё странно работает”, а “на каком именно шаге ломается логика”, “что я ожидал увидеть”, “где проходит граница между проблемой данных и проблемой кода”. Для новичка это почти незаметный, но очень важный сдвиг. Ты перестаёшь просто страдать об задачу и начинаешь с ней разговаривать на более точном языке.

Если смотреть назад, этот проект дал мне не разовый буст уверенности, а более полезную вещь: после него мне стало заметно легче входить в новые предметные области. Я уже знал на опыте, что первая фаза “ничего не понимаю” не означает тупик. Она просто означает начало реальной работы.

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

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

Часто задаваемые вопросы

Как понять, что задача реально сложная, а не просто пугает новизной?

Тест простой: если после пары дней вникания карта задачи не становится понятнее, а только разрастается, — она сложная по-настоящему. Пугающая новизна, наоборот, отступает за 1–2 дня, как только начнёшь читать документацию и открывать код. Сложная задача обычно задевает сразу несколько слоёв: технология, предметная область, чужие ожидания, неполные требования.

Что делать, если на первом сложном проекте начинает накрывать синдром самозванца?

Нормальная реакция, если честно. Работает принцип «дробления неизвестности»: выпишите все неясные места списком и по каждому решите, разбираетесь ли вы сами, спрашиваете коллегу или просите аналитика уточнить у бизнеса. Синдром самозванца обычно прячется в ощущении «я не понимаю всё сразу». Когда задачи становятся конкретными, ощущение слабеет.

Стоит ли новичку браться за проект, который явно выше его уровня?

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

Как правильно документировать первый сложный проект, чтобы потом было чему учиться?

Не пытайтесь писать «финальную документацию». Ведите рабочий лог: что я пробовал, почему не сработало, какая гипотеза оказалась верной. Через полгода именно этот лог окажется ценнее любых красивых схем. Он показывает не «как всё устроено», а «как вы думали» — а это и есть навык, который переносится на следующие проекты.

Что делать, если сложный проект заваливается по срокам?

Сначала поговорить с руководителем и честно расписать, что сделано, что открыто, что неясно. Не «я не успеваю», а «вот список открытых вопросов, вот варианты сокращения scope». Срыв срока сам по себе — не катастрофа, катастрофа — это срыв без предупреждения. Про ответственность разработчика в таких ситуациях я отдельно писал в этом тексте.