Продукт vs проект, и в чем разница для разработчика.

Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.

На деле все проекты едут по срокам, а дом в итоге получается не совсем таким, как его задумывали. И когда дом сдадут, внезапно окажется, что по соседству построили дом для сдачи в аренду посуточно, и там каждый вечер тусовки. Это я веду к тому, что за время проекта может произойти столько всего, что по итогу результат проекта может быть уже никому не нужен.

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

Что это значит для разработчика?

В проекте есть начало и конец. Обычно стараются пилить проект одной командой от начала и до конца. Редко донабирают разрабов в середине. Это значит, что в большинстве случаев это green field, возможность начать с нуля, спроектировать красивую архитектуру и заложить инженерные практики, которые сберегут время в конце проекта, когда сроки будут гореть. Ну а если что-то не совсем правильно спроектировали, то часто выбирают вариант не переделывать, а довести проект до конца и переключиться на следующий.

В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.

Поэтому в продукте так важно «правило бойскаута»:
«оставь место стоянки чище, чем оно было до твоего прихода». Чистка не обязательно должна быть глобальной, достаточно почистить хотя бы небольшой кусок кода, режущий глаз.
© Роберт Мартин

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

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми

Разработчик — больше чем профессиональный кодер

Я программист и я ненавижу встречи — с такой установкой я довольно долго жил. Десять черных квадратиков собрались, побухтели и разошлись. Встречи без четкой агенды, без плана, без цели, без итогов, без визуализации и без камер. Ууу аж трясёт!

Многие встречи могли бы быть письмом. Но есть такие ситуации, которые текстом сложнее и дольше. Например, когда нужно экстренно что-то поправить. Или когда тема слишком неизвестная и нужно побрейнштормить. Или когда нужно чтобы все высказали свое мнение и принять совместное решение. Короче, встречи были, есть и будут, как бы я к ним не относился.

Потом я понял, почему ненавижу встречи. Помните мем "я ограничен технологиями своего времени"? Так и мы. Пока не сделали нейролинк, нам приходится говорить словами через рот. А это ужасно долго. А еще разные люди почему-то понимают одни и те же слова по-разному. А еще кто-то много говорит одно и то же по кругу, а другие отмалчиваются. А еще кто-то обижается, но не понятно на что. А когда все без камер, вообще хрен поймёшь, что там у кого в голове. В общем, разные странности-сложности.

А потом я понял, что раз от встреч никуда не деться, и что это тоже моя работа, то надо быть в этом профессионалом. В продукте профессиональный разработчик — не только профессионально пишет код, но и общается. Доносит свои мысли аргументированно и открыто. Задает вопросы по сути, проясняя нужную информацию. Аппелирует к пользе для продукта при спорах. Не отклоняется от цели коммуникации.

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

Казалось бы, завести в команде фасилитатора и проблема решена. В чем профессионализм и при чем тут разработчик?
А при том. Чем больше фасилитатору приходится вмешиваться и останавливать кого-то или передавать слово, тем больше оверхед встречи. Если сами участники встречи будут чувствовать, что пора передать слово, или что отклоняются от темы, то это будет сильно продуктивнее. Даже встреча может раньше закончиться.

Поэтому в следующий раз, когда будете бугуртить, что встреча долгая и бестолковая, задайте себе вопрос: а что вы как профессионал сделали, чтобы она прошла продуктивно?

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