13 вещей, которые не стоит говорить разработчикам и тестировщикам
Начальник отдела развития проекта 1cloud Сергей Белкин написал для vc.ru колонку о том, какие фразы могут ухудшить рабочую атмосферу в команде ИТ-специалистов и как этого избежать.
При работе в команде люди отвечают не только за себя, но и за окружающих. Как бы банально это ни было, ключ к продуктивному общению - вежливость и взаимоуважение. Есть фразы, которые не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, работодатель или руководитель проекта. Даже если эти фразы звучат вежливо и корректно.
1. «Можешь закончить тестирование поскорее?»
Тестирование нужно проводить вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование - залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот туториалы по автоматизации тестов, предложенные резидентами Stack Exchange), но даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.
В идеале тестирование начинается на этапе проектирования продукта и продолжается до самого релиза, а дизайнеры и разработчики плотно взаимодействуют с тестировщиками. Если в вашей компании происходит иначе - поздравляем, вы узнали, как добиться задержек, ошибок и недостатка бюджета (вот еще несколько вещей, которые не любят слышать тестировщики).
2. «У меня нет времени читать баг-репорт, опиши проблему в двух словах»
Тестировщики (по крайней мере хорошие) тратят много времени и усилий на составление баг-репортов, досконально прописывая все шаги, необходимые для воспроизведения ошибки. Небрежное отношение руководителя или разработчика к отчетам не только означает бесполезную трату времени инженера по тестированию, но и приводит к серьезным проблемам. Всегда читайте баг-репорты.
Однажды я имел неосторожность высказать что-то подобное. Я был молодым специалистом и не имел особого веса в коллективе. Естественно, я услышал заветные два слова, но не про суть багов, а про себя любимого. На восстановление нормальных отношений с тестировщиком ушло не меньше недели.
3. «Обещай мне, что здесь нет багов»
Роль тестировщика - это не контроль качества, а содействие в достижении качества. Задача тестировщика - не проверить, что продукт реализован без ошибок, а узнать, удовлетворяет ли он требованиям компании.
В бизнесе есть поговорка «Обещай меньше - делай больше», поэтому не стоит гнаться за 100% покрытием кода, необходимо сосредоточиться на качестве проводимых тестов. Оставьте экстравагантные обещания отделу продаж и маркетинга. Тестируйте продукты с привязкой к реальности. Кстати, по теме QA есть несколько подкастов, на которые стоит обратить внимание.
4. «Оставь это, я потом сам доделаю»
Эта ошибка встречается сплошь и рядом. Иногда, чтобы завершить задачу побыстрее, вы берете все в свои руки, не ожидая, пока разработчик разберется в проблеме самостоятельно. Советуем вам перестать так делать. Старайтесь выступать в качестве наставника и тренируйте специалистов, чтобы их навыки росли вместе с компанией. Иногда это может казаться страшно неудобным, но в перспективе такой подход очень вам поможет.
Хороший лидер отличается в первую очередь тем, что способен вырастить себе замену. Если все делать за своих сотрудников, они так ничему и не научатся. Вы как владелец проекта должны просчитывать ситуацию наперед: что если завтра я заболею? Если команда может самостоятельно решать проблемы, ничего страшного не произойдет.
Важно избегать ситуаций, когда старшие разработчики выступают менторами большого числа джуниоров, из-за чего у них не остается времени на другие задачи. В таких случаях стоит назначить посредника, который бы занимался менторством и обращался к старшим коллегам только по сложным вопросам. Хорошим решением будет написать собственную документацию и обучающие курсы (вот пара практических советов).
Старайтесь делиться интересными заданиями с подчиненными. За это они вас полюбят.
5. «У меня небольшой вопрос»
Даже если вопрос действительно короткий, ответ на него может и не быть таковым. Для начала поинтересуйтесь, есть ли у коллеги время - сейчас или позже - вам обстоятельно ответить. Дайте возможность отказаться от немедленного ответа и выделить для вас время в будущем.
Если дело срочное, то этим правилом можно пренебречь, но старайтесь не поступать так слишком часто. Вы же не хотите стать менеджером, который кричал: «Волки!».
6. «Я пошел домой» (относится к менеджеру проектов)
Если вкратце, то главная задача менеджера проекта заключается в том, чтобы следить за выполнением работ. Когда процесс стопорится, сотрудники опускают руки или переводят стрелки друг на друга, в работу вступает менеджер проекта, который разбирается в ситуации и находит путь для движения вперед.
Важно быть солидарным со своей командой. Проводите с ними время. Разработчики задержались, чтобы поскорее закончить важный проект? Вам тоже стоит быть на месте: не деморализуйте людей. Сила команды в единстве, поддержке и уважении. Не стоит бросать разработчиков на произвол судьбы в трудный момент.
7. «Вот он сделает это быстрее тебя»
Каждый работает со своей скоростью и имеет сильные и слабые стороны. Кто-то выполняет задачи быстро, а кому-то нужно время подумать. Стоит понимать, что зачастую скорость - это противоположность качеству и затратам.
Обращайте внимание не на скорость работы, а на способность предсказывать, сколько времени потребуется на выполнение задачи. Главное - то, насколько объективно коллега оценивает свои возможности.
8. «Я смотрю, ты уже давно не пишешь код»
В программировании не декларировано количество времени, необходимое для создания строчки кода. Только что написанная функция может требовать время на переосмысление - поэтому, если разработчик уже несколько часов ничего не делает, то он не обязательно уснул (такая вероятность есть, но она крайне мала). Он может искать информацию на форумах и в справочниках или думать, какие изменения стоит внести в код.
9. «Что ты делаешь целый день?»
Этот пункт следует из предыдущего. Хороший программист привыкает задавать себе вопрос «Как мне сделать X хорошо?» вместо «Как мне сделать X?». При этом 95% времени разработчика уходит на размышления о том, как надежно внедрить решение и согласовать его с текущей архитектурой. Остальная часть рабочего дня - это написание кода. Ну, иногда еще пинг-понг и чтение новостных сайтов, таких как Reddit или «Хабр».
10. «Эта задача под силу даже студенту, просто возьми шаблон»
Выдав «студенту» важные задачи, вы рискуете заплатить в два раза больше, если придется все переделывать. Разработчиков очень раздражает, когда заказчик или руководитель оценивает сложность задачи и трудозатраты, основываясь на субъективном опыте. Довольно часто он не обладает профильными знаниями в разработке, но пытается навязать свою оценку.
При оценке сроков и сложности разработки стоит избегать любых неаккуратных фраз. Если слова «Это плевое дело, пара часов максимум» говорит сам разработчик, то задача, скорее всего, действительно будет сделана оперативно.
Если же подобное суждение исходит от менеджера или заказчика, возникает неприятный эффект: разработчику может показаться, что его труд заранее обесценивают. Так что обязательно привлекайте разработчиков и тестировщиков к оценке трудозатрат. Не пытайтесь решить за них, как быстро они могут сделать ту или иную работу.
11. «Глянь вот это, надо срочно сделать»
Работа программиста сравнима с работой людей искусства. Программист сосредоточивается на задаче, как художник, и держит в голове очень сложную картину. Когда вы прерываете его размышления «срочными» делами, он выпадает из потока. Согласно исследованиям, чтобы вернуться в состояние концентрации, человеку требуется не менее 15 минут (почитайте статью о том, как работать в потоке), поэтому просьбы отвлечься крайне раздражают.
Руководителям стоит выстраивать работу таким образом, чтобы утром выдавать задачи, а вечером - принимать готовый результат, не отвлекая команду в середине дня и позволяя каждому трудиться в собственном темпе. Необходимо обеспечить коллегам тишину во время рабочего дня (и речь не о гробовом молчании или запрете на прослушивание музыки в наушниках, а об отсутствии раздражающих разговоров). Тогда эффективность их труда будет гораздо выше.
12. «Никакого рефакторинга, продукт нужен сегодня»
Чем больше в коде «костылей», тем меньше он нравится программистам и тем меньше с ним хочется работать, особенно когда его не дают переписать. Если не следить за состоянием кодовой базы, «грязи» становится так много, что любые изменения приходится вносить с применением хаков. Это ведет к загниванию проекта.
Работа над кодом напоминает игру «Дженга», когда игроки по очереди достают блоки из основания башни и кладут их наверх, делая башню все выше и неустойчивее. Так вот, чтобы башня не упала, нужно время на внесение изменений. Предоставьте команде один день в неделю на рефакторинг, иначе однажды проект придется переписывать с нуля. Рефакторинг способен повысить не только читаемость кода, но и его производительность, что сделает счастливее и ваших клиентов.
13. «Как ты стал разработчиком? Мне бы найти подработку на лето для племянника»
Этот вопрос чаще всего задают люди, имеющие отдаленное представление о создании программных продуктов. Они считают, что современные технологии позволяют написать программу буквально за пару кликов. Да, вспомогательные сервисы упрощают программисту работу, но неопытному человеку популярный фреймворк неизбежно покажется темным лесом.
Поэтому найти подработку на лето вряд ли удастся. А вот за шесть-семь месяцев вполне реально самостоятельно приобрести начальные навыки (с помощью онлайн-курсов, изучения с открытых проектов и так далее), достаточные для работы. Однако это зависит от целевого языка программирования и вакантного места.
Нужно помнить, что работа программиста - не столько профессия, сколько образ жизни. Составляющие успеха в этой сфере - обучение в университете, самообразование, хобби и, что немаловажно, страсть.
