у меня не было привычки показывать промежуточный результат работы. Объяснение этому простое: незаконченная работа может быть неправильно понята, и потому лучше сдавать законченную — на ней легче объяснять. В этом убеждении ошибка. Это не столько касается перфекционизма, про него отдельно. Полностью выполненная работа может оказать не нужна по нескольким причинам:
— на этапе постановки вам сказали не всё; вы поняли не всё; вам сказали что-то не то и тп.;
— на этапе выполнения вас не успели/забыли предупредить о новых вводных; вы отвлеклись или забыли о изначальном ТЗ;
— по завершению работы прошло слишком много времени с момента постановки задачи, и вы просто опоздали.
Конкретная задача скорее всего часть какого-то большего проекта, и если вас ничего не ограничивает от выяснения, что это за проект, и как эта задача влияет на него, в ваших интересах разобраться в их взаимосвязи. Не важно, кто заказчик вашей работы — ваш клиент, ваш коллега, ваш руководитель, вы сами, — понимая связь между всем проектом и задачей вы делаете — это первый шаг на пути к удовлетворительному результату. Второй шаг — это синк (от англ. synchronization), демонстрация промежуточного результата. Такой MVP, первые value которого поверяются с самого начала.
Даже, когда мне стала понятна эта логика, было сложно научиться строить свою работу итерационно. Как определить, достаточно ли данная итерация product или надо ещё допилить? Теперь, зная как быстро можно уйти в своей работе не в нужном направлении, потратить ресурсы и выкинуть часть результата своего труда, регулярная актуализация — обязательный ритуал.
Для ИТ-разработки этот ритуал очевиден. Дейли, викли, синки — всё это часть культуры. Стройке и недвижимости, как отстающим в плане технологизации отраслям, эти полезные практики ещё предстоит внедрить. И мы, кроме непосредственной работы по подготовке жилья к долгосрочной аренде, отстраиваем организационную работу. Чтобы не получалось как в этом меме.