1. Меньше обещать — больше делать.

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

Именно поэтому лучше меньше обещать и больше делать: это значит не спешить с обещаниями и при оценке длительности и стоимости проекта закладывать запас времени и средств на непредвиденные обстоятельства, но всё же стремиться выполнить проект раньше или с меньшими затратами.

Преимущества такого подхода:

1. Достаточно времени на разработку и рефакторинг, а также для того, чтобы исправить накопившийся за годы «технический долг».
2. Возможность создать не просто работающий код, но и спокойно подобрать лучшую архитектуру кода.
3. В процессе разработки многое может пойти не по плану. И по закону Мёрфи всё, что может пойти не так, обычно идёт не так. Неожиданные неприятности могут случиться со всеми, поэтому всегда лучше подстраховаться и заложить некоторый запас в бюджет и расписание.
4. Качественный код как результат пункта 2 и стабильное выполнение проектов в срок как результат пункта 3 создадут разработчику репутацию ответственного человека, который знает своё дело и на которого можно рассчитывать.

Разработчика, оценивающего в 10 недель код, который можно написать за 2 недели, можно посчитать слишком ленивым. Однако если на протяжении проекта постоянно поддерживать коммуникацию с заказчиком, то вопросов с его стороны не возникнет. Разработчик несёт ответственность за оценку проекта, потому что другие люди полагаются на его опыт: именно он лучше всего знаком с кодовой базой, а значит, корректнее всего определит необходимые затраты. Что бы ни случилось во время работы над проектом, открытое общение с заказчиком поможет завоевать доверие и избежать проблем.

2. Лучшее — враг хорошего.

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

Это знакомо и профессионалам, которые стремятся довести проект «до совершенства». Но в мире нет ничего совершенного: везде есть какие-то рамки и ограничения, а любое важное решение имеет свои плюсы и минусы. Главное здесь — признать, что невозможно знать абсолютно всё. На самом деле большинство решений имеет множество альтернатив. Но в конечном итоге каждый человек принимает решение, наиболее правильное с его точки зрения, даже если объективно это не самый разумный выбор.

Лучшее, что можно сделать в этом случае — собрать как можно больше информации, признать риски, когда информация неполная, взвесить все варианты и исходя из этого принимать решение. Хорошая книга на эту тему — «Принципы» Рэя Далио. При этом наихудший вариант развития событий тоже нужно учитывать, а если вероятность того, что многое пойдёт не так, как задумано, слишком велика, можно:

1. попытаться найти решение получше;
2. найти способ максимально снизить риски так, чтобы ими можно было пренебречь.

Как только решение принято, остаётся лишь выполнить его и двигаться дальше.

3. Не отклоняться от курса.

Иногда разработчикам начинает казаться, что продукту не хватает какого-то функционала, что он «сыроват» и никого не заинтересует. Но чаще всё это им действительно только кажется, ведь невозможно угадать, понравится ли продукт пользователям, пока они сами не его испробуют.

Зато вполне реально — поставить чёткую цель в самом начале проекта и придерживаться её, несмотря ни на что. Такой подход имеет два преимущества:

1. помогает преодолеть желание добавлять в продукт всё больше и больше новых функций и сосредоточиться на главном;
2. людям нравится получать быстрый результат. Если есть возможность выпустить продукт за две недели, то лучше так и сделать. Нужно заранее продумать, что продукт должен «уметь» через две недели разработки и сразу же дать его в руки пользователям. Даже если продукт с треском провалится, по крайней мере команде удалось выполнить план и получить ценную обратную связь для дальнейшей работы над ним.

4. Своевременно собирать обратную связь.

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

«Ранний запуск» не означает, что продукт может быть некачественным. Неисправный продукт будет абсолютно бесполезен и лишь покажет неуважение к пользователям. Нужно создать «минимально жизнеспособный продукт» (minimum viable product), который будет обладать минимальными, но достаточными для удовлетворения первых потребителей функциями.

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

5. Искать ответы самостоятельно, прежде чем просить помощи.

Вместо того, чтобы попытаться сначала самим найти ответы, многие начинающие разработчики сразу спешат с вопросами к более старшим коллегам, которые имеют нужный опыт. Но намного полезнее было бы попытаться самостоятельно разобраться в проблеме.

1. Это позволит им глубже изучить новые сферы и освоить новую кодовую базу.
2. По мере развития профессиональной карьеры разработчик будет приобретать всё больший авторитет в глазах окружающих, и к нему начнут обращаться за советом более младшие коллеги. А значит, рано или поздно ему всё равно придётся научиться искать ответы самому, когда рассчитывать будет больше не на кого.

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

6. Чем проще, тем лучше.

Самое сложное в жизни — не усложнять себе жизнь. Часто начинающие разработчики стремятся использовать заумные приёмы и сложные фреймворки, из-за чего код становится слишком неудобным для восприятия. Чаще всего за сопровождение кода отвечают не его авторы, и чем больше он запутан, тем больше проблем возникнет следующих поколений разработчиков.

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

Полезные книги

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

«Как завоевывать друзей и оказывать влияние на людей», Дейл Карнеги — популярная книга, содержащая практические советы и жизненные истории о том, как наладить взаимоотношения с окружающими.

«The Senior Software Engineer», Дэвид Брайант Коупленд — книга рассказывает о том, как развиваться и строить карьеру в сфере разработки.

«Трудные диалоги. Что и как говорить, когда ставки высоки» — Кэрри Паттерсон, Эл Свитцлер, Джозеф Гренни, Рон Макмиллан, К Патерсон — о том, как вести диалог в трудных ситуациях в любой сфере жизни.

«Бизнес с нуля», Эрик Рис — руководство по разработке минимально жизнеспособного продукта для тестирования идеи на рынке.

«Фиолетовая корова», Сет Годин — здесь автор делится опытом, как создать запоминающийся продукт и «зацепить» покупателя.