Этой статьёй я открываю новый цикл «Проект для Исполнителя». Цикл этот я готовил давно, записывал наброски. Но когда захотел выбрать пять правил для первой статьи, то неожиданно увидел, что их у Исполнителя много, и все они важные и правильные. Пришлось некоторые объединить, менее важные — оставить на потом. Остались универсальные, годные не только для команды Исполнителя, но и для всего проекта.
Говорят, перед Новым годом нужно закрыть хвосты, договориться с командой и адекватно спланировать январь. Но кому нужно это геройство?
Определение объема проекта часто воспринимается как сложная и абстрактная задача. На практике это процесс установления четких границ проекта. Он определяет, какие работы входят в проект, а какие находятся за его пределами, что должно быть выполнено, а что делать не планируется. В контексте управления проектами понимание этих границ позволяет согласовать ожидания, избежать недоразумений и обеспечить единое представление о проекте у всех его участников.
В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который независимо от первопричин может «завалить» в первую очередь тестировщиков — сначала фрустрацией от неэффективной рутины, которая превращается в дорогую, медленную и ненадежную «охоту на баги вслепую», а потом и недовольством менеджмента и заказчика.
Спустя годы упорного труда, я, наконец, достиг очередной финансовой цели и купил себе на радостях не просто флэт уайт, а флэт уайт на безлактозном молоке с малиновым сиропом, и, как обычно, погрузился в чтение новостей из мира технологий. И тут пришло осознание, что мои финансовые успехи – это в лучшем случае, песчинка на пляже, где некоторые тру предприниматели строят свой шестиэтажный межгалактический замок. Речь, конечно, о нём. Человеке, который уже вписал себя в историю даже не золотыми, а мифриловыми буквами. Но и это все цветочки, а ягодки, хотя какие там ягодки, здоровые помидоры, будут в 2026-м году.
Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или мейнтейнеров опенсорс-проекта огромный нетестированный PR, ожидая, что всё остальное решится благодаря процессу код-ревью.
Такое поведение грубо, оно заставляет других людей впустую тратить время и идёт вразрез с долгом разработчика ПО.
Ваша задача — выпускать код, который доказанно работает.
Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать (далее…)
Когда говорят о женском лидерстве, чаще всего обсуждают квоты, инклюзию и корпоративную культуру. Это важно, но с точки зрения бизнеса и HR в какой-то момент возникает более приземлённый вопрос: какие конкретно компетенции отличают женщин, которые уверенно выходят в управленческий контур, от тех, кто остаётся на линейных ролях?
Чтобы ответить на него, полезно отойти от общих рассуждений и посмотреть на данные.
Эта статья — не техническая документация для системных администраторов. Это гайд для владельцев бизнеса и ИТ-директоров, которые хотят понять природу «тормозов» в 1С, чтобы эффективно ставить задачи своим техническим специалистам или подрядчикам. Мы намеренно не углубляемся в синтаксис SQL-запросов, а фокусируемся на точках контроля, организационных причинах сбоев и экономике владения системой.
Рано или поздно, если вы стали сеньором, наступает момент, когда вас просят помочь с адаптацией нового сотрудника. Сначала это выглядит как разовая просьба: показать проект, объяснить пару технических нюансов, ответить на вопросы. Потом в команде появляется ещё один новичок. Потом ещё. И в какой-то момент вы вдруг ловите себя на мысли, что ваша роль в проекте незаметно изменилась — вы больше не просто «тот, кто хорошо разбирается в коде», вы стали ментором.
