От джуна до сеньора: Как стать востребованным разработчиком - Владимир Швец

Задание

Попробуйте определить, какой уровень коммуникации на проекте вас больше всего устраивает. Старайтесь соблюдать баланс между полезной коммуникацией и сосредоточенностью на работе. Если вас отвлекают, не стесняйтесь сказать об этом. Обратите внимание и на коллег: какой уровень коммуникации для них предпочтителен?

История из жизни

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

Десять раз спроси, один – напиши

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

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

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

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

Тезисы

■ Спрашивайте.

■ Спрашивайте.

■ Спрашивайте.

■ ОБЯЗАТЕЛЬНО спрашивайте.

Задание

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

История из жизни

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

Критика и критиканство

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

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

Любую критику необходимо воспринимать только как стимул улучшить свои навыки. Никогда не принимайте ее близко к сердцу. Ваша личность никак не связана с профессиональными качествами, работа не связана с вашим «я». Берите в расчет только то, что относится к качеству работы, и пропускайте мимо ушей все, что каким-либо образом затрагивает вашу личность.

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

В некоторых случаях критику будут оправдывать тем, что это «жесткая любовь»: дескать, вас заставляют работать на износ, критикуя практически каждый шаг, чтобы сделать из вас «настоящего спартанца». Никогда не верьте в это. Любая компания, практикующая такое, – не ваша компания (бегите, срочно бегите!). В таком месте вы не сможете развиваться как профессионал. Все, что вы получите, – невроз и комплекс неполноценности.

Тезисы

■ Слушайте и воспринимайте только конструктивную критику, а не критиканство.

■ Меняйте работу, если понимаете, что из вас делают козла отпущения.

■ Никакой «жесткой любви», вы достойны большего. Или поступите как «настоящий спартанец»: сбросьте вашего менеджера со скалы.

Задание

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

История из жизни

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

Пользователь всегда прав

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

Давайте я сразу раскрою основную мысль этой темы: пользователь всегда прав. Всегда. Даже тогда, когда он не прав. Поймите меня правильно: при общении с пользователями в 8 случаях из 10 вы будете сталкиваться с тем, что именно пользователь сделал какую-то глупость, а код работал так, как и должен был работать. Однако вы ВСЕГДА должны считать, что пользователь прав, и проверять каждую ошибку как можно внимательнее.

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

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

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