5 рисков работы над проектом в одиночку — насколько в программировании важна команда

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

Основные риски работы над IT проектом в одиночку

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

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

Ниже мы перечислили пять основных рисков работы программиста в одиночку:

1. Допустить ошибку в backend стороне сайта

Когда frontend специалист становится fullstack, присутствует риск, что backend сторона сайта будет провисать. Если в проекте не будет специалиста, который проведет code review, серверная сторона может содержать баги.

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

2. Не справиться с планированием IT задач

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

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

3. Не заметить ошибки из-за отсутствия тестирования и code review

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

— У тебя не будет code review или каких-либо проверок. Ты будешь сам писать и тестировать — если заказчик не нашел баг, то окей. Тестировщики проверяют различные сценарии взаимодействия с твоим приложением, сайтом. Ты, скорее всего, всех этих сценариев либо не знаешь, либо забьешь на это. Работает и все.

4. Смотреть на проблему однобоко, опираясь только на свой опыт в программировании

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

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

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

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

— По итогу, при одиночной работе, будет просто потрачена куча денег и времени бестолку. В таком нет никаких преимуществ.

Командная работа: почему программисты давно не носят свитера с оленями

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

— В противовес одиночной деятельности, существует способ, когда ты пишешь какую-то часть кода в рамках команды. Например, ты frontend разработчик, а твои коллеги — Project Manager, тестировщик, специалист по backend, также есть заказчик и, желательно, еще техлид. В этом случае — сплошные преимущества.

Планирование и обсуждение — бонусы, которые разработчик может получить только в команде

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

— Команда важна потому, что тебе планируют задачи и вы их обсуждаете. Зачастую, последнее происходит совместно со специалистом по backend. Соответственно, это порождает разные точки зрения, и вы находите наиболее оптимальный вариант.

Роль тестирования в IT проектах

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

— Есть специалисты, которые хорошо протестируют и, опять же, предложат другие сценарии реализации того, что ты сделал. Таким образом можно сделать проект более user friendly.

Обмен опытом критически важен для frontend разработчика

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

Почему code review настолько необходим IT специалисту

Code review необходим потому, что часто только с его помощью можно найти баги до релиза приложения. А это критически важно, так как максимально сложно не привлечь пользователей, а вернуть их после неудачного опыта использования продукта.

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

В каком случае одиночная работа специалиста по frontend не повредит проекту

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

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

29.05.2019
55
Автор: Ася Яскер