Заметки о разработке

, dev

О Проектных Менеджерах (ПМах)

У ПМ в команде несколько ролей. Одна их них — поддерживать спокойный и положительный эмоциональный фон. ПМ должен принимать на себя все эмоциональные удары и другие неприятности исходящие от Владельца Продукта, не давать этим эмоциям просачиваться в коллектив. Хороший ПМ работает как фильтр, сглаживает все эмоциональные перепады в команде.

Хороший ПМ должен хорошо знать продукт, понимать его, чувствовать. Понятно, что для этого нужно время: месяцы, а может даже и годы. Копипастить хотелки из имейлов заказчика в задачи для разработчиков — это работа для секретаря. ПМ пропускает через себя каждую задачу, задает заказчику правильные вопросы еще до технической экспертизы.

Хорошего ПМа незаметно. Хороший ПМ не призывает на митинги больше двух человек. Хороший ПМ умеет вести обсуждения и принимать решения не на митингах, но в имейлах и комментариям к задачам.

(ПМ, с которым мы сейчас работаем, отлично сглаживает отношения с заказчиком, погода в команде нормальная, гонок нет. Наш продукт знает не очень хорошо, но это дело времени.)

О разработчиках

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

Разработчики не любят писать тесты. «Зачем их писать? Я проверил, тут всё работает.» Часто потому, что для тестирования бизнес-процесса нужно проделать много работы, чтобы создать подходящие сущности и окружение. В терминах e-commerce, например, это нужно создать сайт, с продуктами, кастомера с адресами и телефонами, положить эти продукты в корзину, залогинить кастомера и только тогда уже проверить, что для такой корзины и кастомера с таким адресом действует налоговое исключение. Часто написание теста занимает больше времени, чем сама фича или фикс. Вывод: нужно развивать тестовую инфраструктуру и код.

Если говорить о каком-то более-менее стандартном веб-приложении, например, админская часть для e-commerce системы, то на одного бекенд-разработчика нужно два фронтенд-разработчика. Бекенд делать быстро, проще тестировать. Фронтенд — это UI, какая-то клиентская логика, работа с апи, сложнее и дольше тесты.

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

ПМ у меня спрашивает: что мы дадим нашему новому фронтенд-разработчику? Как он у нас будет расти, как он станет профессионалом? А я и отвечаю: Профессионалом становится тот, кто в своё время сделал много черной работы: тупая верстка, поддержка работающего, но адского кода в виде jquery-спагети; переписывание большого скучного легаси. Такая чёрная работа и даёт понимание того, как работает проект, как работает фронтенд, насколько он бывает плох и противен. Писать месяцами на модном фреймворчике — получится рафинированный пользователь фреймворка, который пороху не нюхал.

Разработчики перегорают. Пропадает интерес, запал. Повышение зарплат не помогает, они привыкли к постоянному повышению. Хороший показатель перегорания, когда синьёр разработчик возвращается с уровня проектов, до уровня задач. «Давайте мне таски, я их буду делать.» Вместо: «Давайте мне проект, я буду его делать.»

Очень хочется работать с людьми, которые работают и мыслят не в рамках тасков, но в рамках проекта. Которые думают о взаимосвязях внутри проекта, думают и последствиях, думают о сценариях. К сожалению популярные нынче скрамы и аджайлы немного не про это. Разработчики становятся на конвейер по закрытию тасков. Проект целиком видят только технические лидеры, заказчик (не всегда), ПМ (иногда).