The post has been translated automatically. Original language: Russian
In the early 2000s, I read a lot about Joel on Software. Joel Spolsky wrote not only about code, but also about how programmers, teams, and companies work in general. In January 2001, he published an article about Big Macs vs. The Naked Chef, where he compared two ways of organizing work.
One approach is similar to McDonald's: the process should be described in such detail that the result is predictable regardless of the specific performer. The other is for a good chef who understands the subject, sees the whole situation, and can deviate from the recipe if necessary.
For development, this is an eternal dispute.: what is more important — a good process or a strong specialist?
Over the years, I've seen both answers.
When methodology really Saves
In a large company without processes, chaos begins pretty quickly.
A lot of people, several departments, different interests, approvals, deadlines, documentation, changes in requirements. If everyone acts the way they think is right, the system starts to fall apart.
In such circumstances, the formal methodology sometimes really calms the organization.
It becomes clear who is responsible for what, when a decision is made, what is considered the finished result, and what needs to happen before moving on to the next stage.
Yes, the process may look difficult. Sometimes you have to fill out documents that a small team wouldn't need at all. But for a large organization, this can be the very framework that prevents hundreds of people from going their separate ways.
I have seen projects where, thanks to the methodology, a working product eventually emerged from the corporate chaos.
In this sense, Joel's McDonald's approach works quite well.
But the process easily becomes an end in itself.
There is another side.
Sometimes the customer gets so used to living inside his methodology that he begins to confuse the passage of the process with the solution of the problem.
All the documents are filled out.
All the stages have been completed.
All approvals have been received.
Technically, everything is correct.
But the system itself solves the problem poorly.
And that's where the fun begins.
Sometimes I had to ignore the customer
I have had situations where the customer explained in great detail exactly how, in his opinion, the system should work.
But as they immersed themselves, it became clear that the proposed method did not solve the real problem or made the user experience inconvenient.
Formally, it was possible to simply fulfill the requirements.
It would be safe: the customer asked for it, and the developer did it.
But the result would be a product that no one normally uses.
Therefore, sometimes I had to do it a little differently.
Moreover, the requirements cannot be completely ignored either. The customer needed exactly the option he ordered, and he also had to implement it.
But a second method appeared next to it, the one that, in my opinion, better corresponded to the real process.
And a pretty revealing thing was happening.
In the end, they used my version.
The user votes with a job
This is one of the lessons that is difficult to learn from the methodology.
At a meeting, you can argue for a long time about the right process. You can approve the scheme, write the regulations and sign the terms of reference.
But when the system gets to a real user, a very honest check appears.
Which way does he choose every day?
If the official version requires ten actions, and there is a more convenient way out of three nearby, the user very quickly shows which one is better.
Not a presentation.
Not a document.
Just the way it works.
That is why it can be dangerous to design software based only on a formal description of the process. There is often a big difference between how an organization thinks it works and how people actually do their job.
Joel was right both ways.
I like Joel's article precisely because it is easy to simplify it incorrectly.
We can conclude: "the processes are bad, hire smart people."
But in a large company without processes, strong people get in each other's way very quickly.
The opposite conclusion can be drawn: "everything needs to be described, standardized and no longer dependent on individual specialists."
But then there is a danger that people stop thinking and start just doing the procedure.
In real engineering work, both sides are needed.
Methodology should keep a complex organization from chaos.
And a specialist should understand when a particular situation has ceased to fit into the methodology.
The process sets boundaries, but does not think
A good methodology answers important questions.: who decides what data is needed, what needs to be checked, how changes are recorded, and what result is considered accepted.
But she cannot foresee all situations in advance.
If it were possible, the project itself would most likely have already been fully automated.
That's why I've always found it dangerous to demand "just follow the process."
Sometimes following a process is about professionalism.
And sometimes professionalism consists in noticing in time that the process is leading in the wrong direction.
The main thing is to understand the difference.
And now there's an AI.
In 2026, this topic has become particularly interesting.
AI scales formalized processes very well.
If it is possible to describe the sequence of actions, criteria and expected result, a significant part of such work can be transferred to the agent. In this sense, we have obtained an almost ideal performer for the McDonald's model: he does not get tired of repeating the same procedure and can work with a huge number of instructions.
But there is also a limitation here.
If the instruction is incorrect, the AI will execute it very quickly.
If an organization has incorrectly described its own process, automation will not fix the error. She'll just speed it up.
Therefore, the more work we transfer to AI, the more important the person who is able to ask an unpleasant question becomes.:
Are we automating the right process at all?
AI enhances both good and bad methodology
This is perhaps the main change in recent years.
At least the bad process used to be slow. People got tired, asked questions, circumvented inconvenient rules, and the organization received feedback.
AI can remove some of this resistance.
The process was meaningless, but now the agent executes it in seconds — and it seems to everyone that the problem has been solved.
Although sometimes it was worth not speeding up ten extra steps, but removing them altogether.
Therefore, I do not think that AI will eliminate strong specialists. Rather, on the contrary, it will make people who know how to distinguish the process from the goal even more valuable.
What I learned from my own experience
Over the years, I have not developed a simple position of "methodologies are needed" or "methodologies are in the way."
I have seen how a formal process brought together a large company into one working system and allowed us to bring a complex project to a result.
And I saw the opposite: the customer was so focused on his own methodology that he stopped noticing the meaning of the work. Then we had to formally do what was required, but at the same time build another path that better corresponded to the real task.
The most significant thing was that users then chose this second path.
For me, this is the boundary between process and engineering thinking.
The process is necessary in order not to drown in chaos. But it should not free us from the need to think.
Joel wrote about this more than twenty years ago through a comparison between McDonald's and a good chef.
AI has also appeared next to us today.
But the question remains the same: is it enough to follow the recipe exactly, or sometimes you still need someone who understands exactly what we are trying to cook?
В начале 2000-х я много читал Joel on Software. Джоэл Спольски писал не только о коде, но и о том, как вообще устроена работа программистов, команд и компаний. В январе 2001 года он опубликовал статью Big Macs vs. The Naked Chef, где сравнил два способа организации работы.
Один подход похож на McDonald’s: процесс должен быть настолько подробно описан, чтобы результат получался предсказуемым независимо от конкретного исполнителя. Другой — на хорошего шеф-повара, который понимает предмет, видит ситуацию целиком и может отступить от рецепта, если это необходимо.
Для разработки это вечный спор: что важнее — хороший процесс или сильный специалист?
За годы работы я успел увидеть оба ответа.
Когда методология действительно спасает
В большой компании без процессов довольно быстро начинается хаос.
Много людей, несколько подразделений, разные интересы, согласования, сроки, документация, изменения требований. Если каждый действует так, как считает правильным, система начинает разваливаться.
В таких условиях формальная методология иногда действительно успокаивает организацию.
Становится понятно, кто за что отвечает, когда принимается решение, что считается готовым результатом и что должно произойти перед переходом к следующему этапу.
Да, процесс может выглядеть тяжёлым. Иногда приходится заполнять документы, которые маленькой команде вообще были бы не нужны. Но для крупной организации это может быть той самой рамкой, которая не даёт сотне людей разойтись в разные стороны.
Я видел проекты, где именно благодаря методологии из корпоративного хаоса в конце концов появлялся работающий продукт.
В этом смысле подход McDonald’s у Джоэла вполне работает.
Но процесс легко становится самоцелью
Есть и другая сторона.
Иногда заказчик настолько привыкает жить внутри своей методологии, что начинает путать прохождение процесса с решением задачи.
Все документы заполнены.
Все этапы пройдены.
Все согласования получены.
Формально всё правильно.
Но сама система решает задачу плохо.
И вот здесь начинается самое интересное.
Иногда приходилось не слушать заказчика
У меня были ситуации, когда заказчик очень подробно объяснял, как именно, по его мнению, должна работать система.
Но по мере погружения становилось понятно, что предлагаемый способ не решает реальную проблему или делает работу пользователей неудобной.
Формально можно было просто выполнить требования.
Это было бы безопасно: заказчик попросил — разработчик сделал.
Но результатом стал бы продукт, которым никто нормально не пользуется.
Поэтому иногда приходилось делать немного иначе.
Причём полностью игнорировать требования тоже нельзя. Заказчику нужен был именно тот вариант, который он заказал, и его тоже приходилось реализовывать.
Но рядом появлялся второй способ — тот, который, на мой взгляд, лучше соответствовал реальному процессу.
И происходила довольно показательная вещь.
Пользовались в итоге именно моим вариантом.
Пользователь голосует работой
Это один из уроков, которые трудно получить из методологии.
На совещании можно долго спорить о правильном процессе. Можно утвердить схему, написать регламент и подписать техническое задание.
Но когда система попадает к реальному пользователю, появляется очень честная проверка.
Какой путь он выбирает каждый день?
Если официальный вариант требует десяти действий, а рядом есть более удобный путь из трёх, пользователь очень быстро показывает, какой из них лучше.
Не презентацией.
Не документом.
Просто тем, как он работает.
Именно поэтому проектировать программное обеспечение только по формальному описанию процесса бывает опасно. Между тем, как организация считает, что она работает, и тем, как люди действительно выполняют работу, часто есть большая разница.
Джоэл был прав в обе стороны
Мне нравится статья Джоэла именно потому, что её легко неправильно упростить.
Можно сделать вывод: «процессы плохие, нанимайте умных людей».
Но в большой компании без процессов сильные люди очень быстро начинают мешать друг другу.
Можно сделать и противоположный вывод: «нужно всё описать, стандартизировать и больше не зависеть от отдельных специалистов».
Но тогда появляется опасность, что люди перестают думать и начинают просто выполнять процедуру.
В реальной инженерной работе нужны обе стороны.
Методология должна удерживать сложную организацию от хаоса.
А специалист должен понимать, когда конкретная ситуация перестала помещаться в методологию.
Процесс задаёт границы, но не думает
Хорошая методология отвечает на важные вопросы: кто принимает решение, какие данные нужны, что необходимо проверить, как фиксируются изменения и какой результат считается принятым.
Но она не может заранее предусмотреть все ситуации.
Если бы это было возможно, сам проект, скорее всего, уже был бы полностью автоматизирован.
Именно поэтому мне всегда казалось опасным требование «просто следуйте процессу».
Иногда следование процессу — это профессионализм.
А иногда профессионализм состоит в том, чтобы вовремя заметить: процесс ведёт не туда.
Главное — понимать разницу.
А теперь появился ИИ
В 2026 году эта тема стала особенно интересной.
ИИ очень хорошо масштабирует формализованные процессы.
Если можно описать последовательность действий, критерии и ожидаемый результат, значительную часть такой работы можно передать агенту. В этом смысле мы получили почти идеального исполнителя для модели McDonald’s: он не устаёт повторять одну и ту же процедуру и может работать с огромным количеством инструкций.
Но здесь же находится ограничение.
Если инструкция неверна, ИИ выполнит её очень быстро.
Если организация неправильно описала собственный процесс, автоматизация не исправит ошибку. Она просто ускорит её.
Поэтому чем больше работы мы передаём ИИ, тем важнее становится человек, который способен задать неприятный вопрос:
а мы вообще правильный процесс автоматизируем?
ИИ усиливает и хорошую, и плохую методологию
Это, пожалуй, главное изменение последних лет.
Раньше плохой процесс хотя бы был медленным. Люди уставали, задавали вопросы, обходили неудобные правила, и организация получала обратную связь.
ИИ может убрать часть этого сопротивления.
Процесс был бессмысленным, но теперь агент выполняет его за секунды — и всем кажется, что проблема решена.
Хотя иногда стоило не ускорять десять лишних шагов, а убрать их совсем.
Поэтому я не думаю, что ИИ отменит сильных специалистов. Скорее наоборот: он сделает ещё ценнее людей, которые умеют отличить процесс от цели.
Что я вынес из собственного опыта
За годы работы у меня не появилось простой позиции «методологии нужны» или «методологии мешают».
Я видел, как формальный процесс собирал большую компанию в одну работающую систему и позволял довести сложный проект до результата.
И видел обратное: заказчик настолько концентрировался на собственной методологии, что переставал замечать смысл работы. Тогда приходилось формально сделать то, что требовалось, но одновременно построить другой путь, который лучше соответствовал реальной задаче.
Самое показательное было то, что пользователи потом выбирали именно этот второй путь.
Для меня это и есть граница между процессом и инженерным мышлением.
Процесс нужен, чтобы не утонуть в хаосе. Но он не должен освобождать нас от необходимости думать.
Джоэл писал об этом больше двадцати лет назад через сравнение McDonald’s и хорошего шеф-повара.
Сегодня рядом с нами появился ещё и ИИ.
Но вопрос остался тот же: достаточно ли точно следовать рецепту или иногда всё-таки нужен человек, который понимает, что именно мы пытаемся приготовить?
Share
