«Молчание – золото»: 13 вещей, которые не стоит говорить разработчикам и тестировщикам
/ фото Sistema Bibliotecario Vimercatese CC
Практически каждая крупная организация нанимает в свой штат разработчиков программного обеспечения. При этом только треть из них заняты непосредственно в бизнесе, связанном с ИТ. Но вне зависимости от того, где они работают: в фармацевтической компании, образовательной или рекламной сферах, они остаются программистами.
Работа в команде — ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые — даже когда они звучат вежливо и корректно — не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.
1. «Можешь закончить тестирование поскорее?»
Тестирование должно проводиться вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование — залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот несколько туториалов по автоматизации тестов, предложенные резидентами Stack Exchange), однако, даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.
В идеале тестирование начинается еще на этапе проектирования продукта и продолжается до самого релиза, а дизайнеры и разработчики плотно взаимодействуют с тестировщиками. Если в вашей компании происходит иначе, то, поздравляем, вы узнали рецепт задержек, ошибок и недостатка бюджета (вот еще несколько вещей, которые не любят слышать тестировщики).
2. «У меня нет времени читать баг-репорт, опиши проблему в двух словах»
Тестировщики (по крайней мере, хорошие) тратят много времени и усилий на составление баг-репортов, досконально прописывая все шаги, необходимые для воспроизведения ошибки. Подобное небрежное отношение руководителя или разработчика приводит не только к бесполезной трате времени инженера по тестированию, но и другим серьезным проблемам. Всегда читайте баг-репорты!
Не стоит недооценивать этот совет: однажды я имел неосторожность высказать что-то подобное. На тот момент я был молодым специалистом и не имел особого веса в коллективе. Естественно, я услышал заветные два слова, но не про суть багов, а про себя любимого… На то, чтобы восстановить нормальные отношения с тестировщиком ушло не меньше недели.
3. «Обещай мне, что здесь нет багов»
Роль тестировщика — это не «контроль качества», а «содействие в достижении качества». Задача тестировщика — не проверить, что продукт реализован без ошибок, а убедиться в том, что он удовлетворяет (или не удовлетворяет) определенным требованиям компании.
В бизнесе есть поговорка: «Обещай меньше, делай больше», потому не стоит гнаться за 100% покрытием кода, необходимо сосредотачиваться на качестве проводимых тестов.
Оставьте экстравагантные обещания отделу продаж и маркетинга — пусть они этим занимаются. Тестируйте продукты с привязкой к реальности. Кстати, по теме QA есть несколько подкастов, на которые вам стоит обратить внимание.
4. «Оставь это, я потом сам доделаю»
Эта ошибка встречается сплошь и рядом. Иногда, чтобы завершить задачку побыстрее, вы берете все в свои руки, не ожидая, пока разработчик разберется в проблеме самостоятельно. Мы советуем вам перестать так делать. Старайтесь выступать в качестве наставника и тренируйте специалистов, чтобы их навыки росли вместе с компанией. Иногда это может казаться страшно неудобным, но в перспективе такой подход очень вам поможет.
Хороший лидер отличается, в первую очередь, тем, что способен вырастить себе замену. Если все делать за своих сотрудников, они так ничему и не научатся. Как владелец проекта, вы должны просчитывать ситуацию наперед. Что если завтра я заболею? Если команда может самостоятельно решать проблемы, ничего страшного не произойдет.
Однако важно избегать ситуаций, когда старшие разработчики выступают менторами большого числа джуниоров, из-за чего у них не остается времени на другие задачи. В таких случаях стоит назначить некоего посредника, который бы занимался менторством и обращался к старшим коллегам только по сложным вопросам. Также хорошим решением будет написать собственную документацию и обучающие курсы (здесь вы найдете пару практических советов).
Важно: старайтесь делиться «вкусными» и интересными заданиями с подчиненными. За это они вас полюбят.
5. «У меня небольшой вопрос…»
Фраза не самая удачная. Даже если вопрос действительно окажется коротким, ответ на него таковым может и не быть. Попробуйте поинтересоваться для начала, есть ли у коллеги время (сейчас или в будущем) вам обстоятельно ответить. Дайте собеседнику возможность отказаться от немедленного ответа и выделить для вас свободное время в будущем.
Если дело срочное, то этим правилом можно пренебречь, но старайтесь не поступать так слишком часто. Вы же не хотите стать менеджером, который кричал: «Волки!».
6. «Я пошел домой» (относится к менеджеру проектов)
Если вкратце, то главная задача менеджера проекта заключается в том, чтобы следить за выполнением работ. Когда процесс стопорится, сотрудники опускают руки или переводят стрелки друг на друга за ошибки, в работу вступает PM, который разбирается в ситуации и находит путь для движения вперед.
Важно быть солидарным со своей командой. Проводите с ними время. Разработчики задержались, чтобы поскорее закончить важный проект? Вам тоже стоит быть на месте — не деморализуйте ваших людей. Сила команды в единстве, поддержке и уважении. Не стоит бросать разработчиков на произвол судьбы в трудный момент.
7. «Вот он сделает это быстрее тебя»
Каждый работает со своей скоростью и имеет собственные сильные и слабые стороны. Кто-то выполняет задачи быстро, а кому-то нужно время подумать. Однако стоит понимать, что зачастую скорость — это противоположность качеству и затратам.
Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное — это то, насколько объективно коллега оценивает свои возможности.
8. «Я смотрю, ты уже давно не пишешь код»
В программировании не декларировано количество времени, необходимое для создания строчки кода. Только что написанная функция иногда может требовать время на переосмысление, поэтому если разработчик уже несколько часов ничего не делает, то он не обязательно уснул (такая вероятность есть, но она крайне мала), он может искать информацию на форумах и в справочниках или думать, какие изменения стоит внести в код.
9. «Что ты делаешь целый день?»
Тема, вытекающая из предыдущего пункта. Хороший программист привыкает задавать себе вопрос «Как мне сделать X хорошо?» вместо «Как мне сделать X?». При этом 95% времени разработчика уходит на размышления о том, как надежно внедрить решение и согласовать его с текущей архитектурой. Остальная часть рабочего дня — это написание кода. Ну, иногда, еще пинг-понг и чтение новостных сайтов, таких как Reddit или Хабр.
Если человек уже несколько часов не пишет код, это не означает, что он ничего не делает, скорее всего, он ищет красивое и грамотное решение. Рекомендуем почитать эту статью, в которой рассказывается, почему не стоит оценивать работу программиста только по «внешнему виду».
10. «Эта задачка под силу даже студенту, просто возьми шаблон»
Выдав «студенту» важные задачи, вы рискуете заплатить в два раза больше, если придется все переделывать. По своему опыту мы в 1cloud можем сказать, что разработчиков очень раздражает, когда заказчик или руководитель дает оценку сложности задачи и трудозатрат на разработку, основываясь на своем субъективном опыте. При этом довольно часто руководитель не обладает профильными знаниями в разработке, но пытается навязывать разработчику свою оценку.
В целом стоит избегать любых неаккуратных фраз при оценке сроков и сложности разработки. Например, фраза «Это плевая задача, пара часов максимум…», высказанная самим разработчиком, говорит о том, что задача, скорее всего, действительно будет сделана оперативно.
Если же подобное суждение исходит от менеджера или заказчика, возникает неприятный эффект: разработчику вполне может показаться, что, называя задачу «плевой», заказчик заранее обесценивает его труд. Так что обязательно привлекайте разработчиков и тестировщиков к оценке трудозатрат, не пытайтесь решить за них, как быстро они могут сделать ту или иную работу.
11. «Глянь вот это, надо срочно сделать…»
Работа программиста сравнима с работой людей искусства. Программист сосредотачивается на задаче, как художник, и держит в голове очень сложную картину. Когда вы прерываете его размышления «срочными» делами, он «выпадает» из потока. Согласно исследованиям, чтобы вернуться в состояние концентрации, человеку требуется не менее 15 минут (почитайте статью о том, как работать в потоке), поэтому отвлечение крайне раздражает.
Руководителям стоит попытаться выстроить работу таким образом, чтобы утром выдавать задачи, а вечером — принимать готовый результат, лишний раз не отвлекая команду в середине дня и позволяя каждому трудиться в собственном темпе. Необходимо обеспечить коллегам тишину во время рабочего дня [и речь, скорее, не о гробовом молчании и/или запрете на прослушивание музыки в наушниках, а об отсутствии раздражающих разговоров] — эффективность их труда будет гораздо выше.
12. «Никакого рефакторинга, продукт нужен сегодня!»
Чем больше в коде «костылей», тем меньше он нравится программистам, и тем меньше с ним хочется работать, особенно тогда, когда его не дают переписать. Если не следить за состоянием кодовой базы, «грязи» становится так много, что любые изменения приходится вносить с применением хаков. Это ведет к загниванию проекта.
Работа над кодом напоминает игру «Дженга», когда игроки по очереди достают блоки из основания башни и кладут их на верх, делая башню всё более высокой и все менее устойчивой. Так вот, чтобы башня не упала, требуется время на внесение изменений. Предоставьте команде один день в неделю на рефакторинг, иначе однажды проект придется переписывать с нуля. Рефакторинг способен повысить не только читаемость кода, но и его производительность, что сделает счастливее и ваших клиентов.
13. «Как ты стал разработчиком? Мне бы найти какую-нибудь подработку на лето для племянника/знакомого/и т.д.»
Этот вопрос чаще всего задают люди, имеющие отдаленное представление о создании программных продуктов. Они считают, что современные технологии позволяют написать программу буквально за пару кликов мышки. Да, вспомогательные сервисы упрощают работу программисту, но для неопытного человека популярный фреймворк может показаться [и неизбежно покажется] темным лесом.
По этим причинам найти подработку на лето вряд ли удастся. А вот за 6–7 месяцев, при должном усердии, вполне реально самостоятельно приобрести начальные навыки (с помощью онлайн-курсов, изучения с открытых проектов и так далее), достаточные для работы. Однако это зависит от целевого языка программирования и вакантного места.
Главное — помнить, что работа программиста — не столько профессия, сколько образ жизни. Обучение в университете, самообразование, хобби и, что немаловажно, страсть — ключевые составляющие успеха в этой сфере.
В своей трудовой деятельности мы, пожалуй, столкнулись почти со всеми перечисленными ситуациями. И любая из них может легко выбить разработчика/тестировщика из колеи. Конечно же, бессмысленно «устанавливать запрет» на какие-то слова — важно просто понимать, что вы хотите донести до коллеги, и к каким последствиям такое решение или поступок приведет.
Поэтому в процессе разработки IaaS-провайдера 1cloud мы стремимся к тому, чтобы все специалисты, в том числе и разработчики, обладали довольно большой степенью свободы в проекте и несли ответственность за результат по принятым решениям. Это позволяет менеджерам и разработчикам чувствовать себя одной командой и оперативно решать любые спорные или скользкие моменты в личном общении — когда все сотрудники понимают, что их труд значим, их мнение учитывается, недопонимания в процессе разработки получается избежать — даже если «запретная фраза» и произносится.
Комментарии (3)
5 июля 2016 в 11:39
+2↑
↓
Спасибо, хорошая статья. О мелочах, которые сам человек не замечает, но которые могут сильно раздражать окружающих.
1cloud
5 июля 2016 в 12:01
+2↑
↓
Стараемся обращать внимание на мелочи :)
5 июля 2016 в 12:00
0↑
↓
C точки зрения человека, который пытается быть хорошим PM (и с т.з. PMBoK) п.6 некорректен, а точнее — описывает плохого PM.
Хороший не столько следит за выполнением работ, сколько перед началом работ составляет вменяемый план работ и действия на случаи отклонения от этого плана. Если все внезапно пошло не так, и надо срочно придумывать, что делать — это факап PM’а.
В реальности, конечно, все чуть сложнее и в небольших конторах с т.з. руководства часто PM еще и продажник, тестер, немного тимлид и еще и курьер по совместителству.
