Качество работы штатного программиста. Как оценивать?

Здравствуйте,

У нас небольшая компания, пилим свой сайт, црм и подобные штуки для внутреннего использования. Технологии обычные: yii2, mysql etc. 3 штатных программиста, и я как ПМ (сам не разработчик, но технарь). Используем JIRA+Bitbacket. Тестов нет, я сам вручную тестирую закрытые таски на предмет ошибок.

Проблема:
Практические все закрытые разработчиками задачи содержат ошибки, причем очевидные, которые сразу бросаются в глаза при минимальном тестировании. И я не понимаю, это вообще нормально или нет? Разработчик должен пушить код, в котором он уверен с высокой степенью вероятности или это так и принято, что пушишь и нифига не тестируешь, типа как-то там сами тестеры разберутся?
Честно говоря, меня такое довольно наплевательское отношение к качеству кода не устраивает.
Что посоветуете? Брать тестера? Менять разработчиков? Менять процессы? Может в джире сделать подсчет возвратов задач в доработку по причине бага и на этом основании депремировать или как? Или наоборот давать премию за выполнение задач без багов?
  • Вопрос задан
  • 827 просмотров
Пригласить эксперта
Ответы на вопрос 13
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Со словами "ошибки достойные джуна" разработчик понижается до младшего с соответствующей записью в трудовую и снижением зарплаты, а при рецидивах увольняется по статье за профнепригодность.
Ответ написан
AlexZaharow
@AlexZaharow
Программист.
О, да. Я разработчик и надо мной есть начальники и у меня обратная ситуация, что считают, что я слишком много уделяю внимания обработке ошибок.)))
Видимо кто-то не очень готов к своей работе. Поясню. Любая программа решает не меньше двух задач. Первая - сделать всё правильно при правильных исходных данных и Вторая - не делать первой работы при неправильных исходных данных.
Поскольку первую часть работы сделать относительно просто в силу очевидности, то делать вторую всегда качественно сложнее по причине именно неочевидности. Ну и ещё этому обычно не учат. Обычно все заканчивается на try/catch и думают, что этого достаточно.
Что касается программистов, то обычно с них трудно спросить, почему они не предусмотрели ту или иную обработку ошибок, т.к. они могут быть не в курсе контекста решаемой задачи и что там могут быть за ошибки и за это скорее должен отвечать руководитель проекта (единственная очевидная ошибка - деление на ноль. Всё остальное нужно рассматривать в контексте).
С другой стороны, когда вы выбирали программистов, то стоило бы проверить у них чувство «вкуса» на ошибки, так что тут вопрос тоже к вам.
Не могу дать именно вам однозначного совета, но я бы пообщался с разработчиками на предмет желания делать качественно свою работу, обозначил срок проверки и довёл бы прозрачные параметры оценки работы (возможно и с субъективной оценкой, вы же начальник))). После окончания срока самого слабого увольняете. Ещё до окончания срока оценки можно начать искать сотрудника на бушующее вакантное место, ну, чтобы лучше мотивировать остальных. Понятно, что это стресс для всех, но вполне себе радикальное средство, как химиотерапия, к которому можно прибегнуть, когда ситуация критическая.
Но вам тоже нужно и над собой поработать, чтобы научиться избегать таких проблем, чем их решать. Если вы человек опытный, то делитесь своими знаниями, чтобы ваши разработчики учились у вас, но и вы тоже должны у них учиться, т.к. их опыт тоже постоянно увеличивается и его можно позаимствовать. В общем у вас сейчас слабая обратная связь, раз вы узнаете о проблеме уже после выполнения работы. Я бы какое-то время посидел бы с разработчиками, чтобы посмотреть как они вообще работают, но, чтобы не отсвечивать делал бы какую-то задачу. Вдруг у вас в технологии разработки какая-то проблема, которая мешает качеству?
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
>это вообще нормально или нет?
да это нормально, разработка всегда идет от плохого к хорошему, постепенными улучшениями, никогда сразу не создаются хорошие версии продукта.
С этим разобрались
Разработчик самостоятельно решает какой должен быть минимально приемлемый уровень качества. Если вы считаете такой уровень не достаточным, значит нужно заранее задавать эти стандарты хотя бы в виде тестов.
Почему такая система сложилась? -
возможно это как-то завязано на системе мотивации которую вы используете, например вы оплачиваете только за выполнение таски (значит самая первая и самая примитивная версия сразу выдается клиенту)
Возможно сами требуете скорейшего выполнения задачи. Как вариант конечно разработчик не знает как сделать лучше (это тоже не проблема, надо просто еще взять сотрудника у которого квалификация будет чтоб подтянуть команду).
Тестеров в начале не стоит набирать - лучше платите своим разработчикам чтоб они друг друга работу тестировали, что позволит им самим качественно вырасти.
По поводу посчета возврата к задаче -> при желании можно сколь угодно долго находить баги в любой задаче (вы не можете конечным алгоритмом охватить бесконечно сложную реальность). Так что это бессмысленно.
Самое худшее что вы можете сделать - начать накладывать какие-то санкции, за то что программист якобы НЕ сразу выдал "идеал в вакууме".
Качество всегда будет стоить дополнительных денег и времени.
Остается постепенно искать баланс между качеством, стоимостью и затраченным временем.
По поводу оценки компетенций, да она понятно у них она очень низкая - вы же не гугл и не эпл, и даже не сбербанк технологии, вам гарантированно закрыт доступ не то что к крутым, даже к разработчикам условно "среднего уровня", все что вам остается взять то что осталось на рынке, и научится с этим хоть как-то работать. Ну конечно попробуйте искать людей с более высокой квалификацией, может кто и найдется, но принципиально уровнем выше вы просто в свою компанию не найдете (гарантирую)
Ответ написан
@mletov
Тут надо понимать, что взгляд программиста и непрограммиста на критичность ошибок несколько разнится.

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

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

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

Поэтому вам не зря написали: чтобы маломальски объективно оценивать труд программиста, нужно самому быть программистом. Задумайтесь, не является ли ваш взгляд на проблему поверхностным. Может быть в проекте так много мелких ошибок потому что все силы программисты бросили на решение ключевых вопросов?
Ответ написан
profesor08
@profesor08
  1. Без внятного тз - результат хз.
  2. Результатом работы, в условиях жестких сроков, будет минимально рабочий вариант, об учете нюансов и речи быть не может.
Ответ написан
riky
@riky
Symfony / Laravel
Честно говоря, меня такое довольно наплевательское отношение к качеству кода не устраивает.

а вы им точно это говорите?

PS не обязательно на них наезжать, можно просто спросить их "что мы можем сделать чтобы таски закрывались с меньшим количеством доработок?".
Я уверен что и вы и они у вас взрослые люди, сами свою ситуацию лучше видят.

Если они могут сказать только что "и так сойдет", то премиями вы замучаетесь все исправлять.
Также взять тестера вполне может быть вариант - если есть человек который за меньшие деньги освободит дорогое ваше время и время ваших разработчиков - то почему бы и нет, все смогут тратить его на более сложные вещи.
Ответ написан
vt4a2h
@vt4a2h
Senior software engineer (C++/Qt/boost)
1) Разработчик должен покрывать свой код тестами. Хотя бы юнит-тестами. Это настолько очевидно, что даже не подлежит обсуждению. Такой подход экономит тонны денег и человеко-часов.
2) Всё тесты интегрированы в CI и запускаются на каждый пуш.
3) Интеграционные тесты тоже надо писать.
4) Возможно стоит нанять отдельного человека для написания системных тестов.

А дальше всё просто: разработчик запушил, сломал, чинит. Ну а правильное покрытие тестами уберёт процентов 90 багов, которые могут заново появиться, хотя уже и были закрыты.
Разработчиков, которые не могут тестировать свой код, надо увольнять и менять на тех, которые могут.
Ответ написан
zoonman
@zoonman
CEO @ LinuxQuestions.ru
У нас небольшая компания, пилим свой сайт, црм и подобные штуки для внутреннего использования.

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

Тестов нет, я сам вручную тестирую закрытые таски на предмет ошибок.

Дальше можно не продолжать. Отсутствие тестов - индикатор низкого уровня разработки, как результат - плохой код на выходе. Это ваша вина, как лидера группы.

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

Очевидно для вас, неочевидно для разработчика. Реализация напрямую зависит от постановки задачи. Если вы предоставили плохое/нечеткое ТЗ, то будут косяки. Опять же ваша вина.

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

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

Что посоветуете?

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

Итак, что же нужно сделать в такой ситуации.

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

1. Пересмотреть подход к постановке задач. Недаром в Agile имеется такой пункт, как сценарий использования. Это и есть ваш тест. Если разработчик выполняет сценарий и баг возникает, значит его косяк. Решается возвратом тикета на доработку. Если тестовый сценарий хоть на йоту отличается - ваш.

2. Внедрить юнит и интеграционное тестирование, как часть процесса разработки. Разработка будет в 2-3 раза дольше. Это нормально. Зато качество кода существенно улучшится и количество ошибок уменьшиться. Внедрение тестирования достаточно болезненный этап и занимает около года на перестройку мышления.

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

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

Напоследок. Ошибки бывают даже при самых лучших практиках и замечательной мотивации. Это природа человеческой натуры. Не будьте чересчур строги к подчиненным.
Ответ написан
>Брать тестера? Менять разработчиков?
Оба варианта возможны.

Если разрабы получают много денег и сроки жёстко на них не давят - вы вправе ожидать высокого качества кода. В этом случае, неплохо было бы их направить в правильное русло: например, попросить их составлять план тестирования (в виде простенькой доки) после выполнения задачи и присылать вам его "на проверку", после чего вы бы отправляли "утверждённый" план им назад с просьбой выполнить его. Если люди саботируют это - вы вправе с ними попрощаться (либо же они уйдут сами :))).

Если же разрабы получают не сильно много (либо у них жёсткие сроки) - то либо нанимать новых, подороже, либо брать тестера. Лично я сторонник первого пути в случае небольших команд (5-6 разрабов) - найми правильных людей и у тебя, как руководителя, сразу исчезнет проблема "нужно всё перепроверять, а местами и переделывать". А вот для команд побольше, как мне кажется, нужен системный подход - отдельные тестировщики.
Ответ написан
gangstarcj
@gangstarcj
У меня тоже достаточно много "банальных" ошибок в приложении. Часто когда пишешь код, сосредотачиваешься на чем-то сложном, а на простое тратишь меньше ресурсов.
Избавиться от таких ошибок мне помогают проработанные чек-листы и их соблюдение. Писать их лучше вам самому, а не давать разработчику. Если не отмечены все пункты, значит нельзя пушить в гит.
Например чек-лист для формы обратной связи:
- Поле Имя обязательно к заполнению
- Поле Имя проверяется на фронте
- Поле имя проверяется на бэке
- Поле телефон имеет маску +7(000)-000-00-00
- Поле эмейл проверяется на формат ааа@bbb.zz
- Чек-бокс обязателен
- Ссылка в описании чекбокса ведет на страницу /privacy.html
- Кнопка отправить блокируется во время отправки аякса
- Если есть ошибки, они выводятся
- Выводится текст об успешной отправке
- Письмо уходит на эмейл zzz@xxx.aa
Ответ написан
sfi0zy
@sfi0zy
UI developer. Верстаю неверстаемое.
Что посоветуете? Брать тестера? Менять разработчиков? Менять процессы?


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

А как придет понимание, что есть пользователи и нужно о них заботиться, уже можно говорить о внедрении планок качества или об автоматизации тестирования. Можно начать не с хардкорного TDD, а с более мягкого подхода, соответствующего этой идее: взять что-нибудь вроде codecept.js и по-быстрому описывать сценарии взаимодействия пользователя с системой. Сначала основные, которые обязательно должны работать, потом альтернативные, где обработка ошибок происходит. Собственно и изначальное ТЗ формулировать в виде сценария взаимодействия. Можно отвести под тесты отдельный сервер (ненужное железо всегда можно где-нибудь найти). Потом, как привыкнут, попробовать покрывать все юнит тестами или еще что-то внедрять, своим примером показывая, что это и правда может экономить время на поиск багов или давать какие-то еще полезности. Иными словами стоит сначала перестраивать мышление, а потом уже улучшать технические моменты.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
У нормального проекта архитектура кода не даёт возможности сделать ошибку.
1. Обратите внимание на архитектуру и устраните все повторяющиеся блоки с одинаковым кодом, разнесите зоны действия переменных по функциональным блокам.
2. Документируйте в схематичном виде и при разработке - всегда согласуйте межблочный интерфейс и функционал разрабатываемого функционального блока.
3. Никаких нативных сборов пользовательских переменных, прямых запросов к БД, доступов к произвольным объектам - вся работа должна контролироваться верхним слоем архитектуры и все доступы и манипуляции обеспечиваться единым контроллером (классом) для каждого из действий.
Ответ написан
@abmanimenja
Нужно дать обратную связь.

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


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


Что посоветуете? Брать тестера? Менять разработчиков? Менять процессы? Может в джире сделать подсчет возвратов задач в доработку по причине бага и на этом основании депремировать или как? Или наоборот давать премию за выполнение задач без багов?


Ошибки в коде - это нормально.
Есть приблизительная статистика: разработка состоит на 80% времени в вылавливании багов. И только на 20% времени в создании нового.

То есть исправление ошибок (за деньги тоже) такая же нормальная работа, как и собственно написание кода.

Это понятно, что не хочется платить за ошибки, но если вы будете платить только за новый код без ошибок - вам придется поднять зарплаты в 5 раз.

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

Только учесть, что огромное количество времени уходит на исправление ошибок и 100% отсутствия ошибок добиться невозможно - это единственное, что относится к специфики разработки ПО.

Сначала мягко пожурить, потом серьезно пожурить, потом депримировать (или отменить "автоматическую" премию), потом уволить.

Главное чтобы было четко понятно - "за что именно".

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы