Как программисту оценить свой темп работы — отвечают эксперты

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

Евгений Лопатин

директор департамента разработки «Инфосистемы Джет»

Существует такой «факт» в разработке — скорость работы двух программистов может различаться в десять раз, при этом зарплата будет различаться максимум в три! Так как оценить свой темп?

Темп можно измерять своим внутренним ощущением: «Мне модель надо закодить, реализовать API из 10 методов, а я всё ещё пакет utils наполняю». Можно мерить темп в сравнении: «Вася вон уже три отчёта поправил, а я с первым вожусь». Кроме того, темп действительно может оценивать руководство: «Ну что он там возится с этой формой, UI же простой, вот его предшественник давно бы всё сделал…».

Скажу по секрету как руководитель, неважно, какой темп у программиста, главное, чтобы он умел выдерживать заданную скорость работы (как минимум не снижать её) на длительном временном интервале. Это позволяет более точно планировать работу, получать ожидаемый результат к назначенному сроку. Тот, у кого темп сильно зависит «от настроения», добавляет в проект больше рисков.

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

Важно отметить, что темп — это не просто скорость написания кода. Это комплексное понятие. Можно быстро закодить, потом потратить ещё вдвое больше времени на багофикс. Это не есть высокий темп. Даже если код без ошибок (ну хорошо, не без, а тестировщики и/или пользователи ещё не нашли), а архитектура такова, что любая правка занимает уйму времени — тоже так себе результат. Поэтому при оценке стоит принимать во внимание множество факторов: скорость кодирования, качество кода, сопровождаемость кода, читаемость, комментарии и т. п.

Ещё одним важным аспектом является умение оценивать сроки. Тот, кто точнее оценивает сроки на разработку и их выдерживает, всегда будет иметь лучший темп. Я не говорю о варианте «а назову срок побольше, если что, найду чем заняться…».

Попробуйте оценить сложность задач коллег и посмотреть на их скорость и качество результата. Сравните со своими показателями. Мой совет — не стремитесь быть самым быстрым, стремитесь быть стабильным и непрерывно повышайте свою квалификацию. Чем больше практики и знаний современных инструментальных средств, умений работать с нужной IDE и правильно её настраивать, пользоваться отладчиками, эмуляторами, фреймворками и прочим, тем выше скорость работы.

Владимир Кузнецов

программист Galileosky

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

Программист может объективно сказать, что работает медленно, только если к нему пришли с вилами и факелами и сообщают, что дедлайн прошёл уже очень давно. А если серьёзно, то важно понять две вещи:

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

Сергей Ширкин

декан факультета Искусственного Интеллекта в онлайн-университете GeekUniversity

Нужно понимать, что в погоне за скоростью программирования может потеряться качество.

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

Если в компании применяются методологии наподобие Agile, то, как правило, крупные программистские задачи разбиваются на более мелкие, и каждой из них присваивается определённое число поинтов (поинт чаще всего соответствует одному дню). Помимо объёма задачи и её сложности, в поинты закладывают риски. Сроки могут впоследствии корректироваться — в таком малопредсказуемом деле, как разработка, это вполне нормально.

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

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

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

Светлана Гацакова

директор департамента корпоративных информационных систем ALP Group

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

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

Поэтому программисту нужно оценивать свой темп работы основываясь на экспертном мнении системного архитектора.

Андрей Клюев

ведущий разработчик MediaSoft

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

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

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

Не менее важным аспектом в поддержке нормальной скорости разработки является концентрация на одной задаче. Если вы постоянно прыгаете от одного задания к другому, переключаетесь с ветки на ветку или ещё хуже — с проекта на проект, то работать вы будете медленнее, даже если вы матёрый программист с многолетним опытом. Ну и о дисциплине забывать не стоит: установите себе менеджер экранного времени и посмотрите статистику, на что вы тратите своё время. Если на первом месте у вас будет tproger.ru, а не ваша любимая IDE, то стоит задуматься. ?

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

Сергей Комаров

директор департамента информационных решений компании РДТЕХ

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

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

Владислав Сивачук

руководитель проектов в Inyh

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

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

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

Что касается перфекционизма в архитектурных решениях и непосредственно в программном коде — это довольно скользкий момент и необходимо найти нужную грань, а точнее — нужное время и нужный этап для этого перфекционизма. Разумеется, писать структурированный и хорошо задокументированный (закомментированный) код необходимо любому уважающему себя и других разработчику, но при любой разработке я бы советовал всем придерживаться правила «Do it. Do it right. Do it better», что в вольном понимании означает «Сначала просто сделай, потом сделай правильно, затем уже сделай лучше».

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

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

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

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

Любая оценка относительна и, как правило, относительно коллектива, в котором работаешь.

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

Андрей Шифрин

менеджер группы разработки карты рассрочки «Совесть»

Скорость — вещь субъективная, сама скорость не может быть единственной метрикой. Есть еще такие показатели, как качество кода, покрытие тестами, простота (в хорошем смысле, облегчающая его поддержку) и т. д. Можно писать быстро, но выпускать полный треш. В этом плане, наверное, правильнее говорить о некоторой эффективности, которая включает в себя множество факторов. На эффективность влияют много вещей, но среди базовых можно выделить опыт и тайм-менеджмент. Легче всего проседание в этих компонентах можно заметить работая в команде, как говорится «всё познается в сравнении». Работая в команде легче перенимать опыт у коллег. Также если ты видишь, что равные тебе по скиллам коллеги работают эффективнее, стоит посмотреть, на что ты тратишь время в течение дня, как часто ты переключаешь контекст, сколько у тебя неучтенных активностей. Поработав над этим, можно сильно поднять свою эффективность.

Данил Головизин

продакшн-директор digital-агентства Rutorika

«Медленно» — это относительная величина. Обычно в компаниях есть грейды: джун, мидл, сеньор, которые указывают на опыт разработчика и определяют зарплату. Логично, что джун работает медленнее мидла, а мидл медленнее сеньора. В таких компаниях старшие разработчики могут объяснить, почему ты работаешь медленно и куда нужно расти.

Скорее всего, вопрос про случаи, когда в компании один разработчик на конкретном стеке. Ему не у кого учиться и не с кем себя сравнивать. Если руководитель говорит, что разработчик медленно работает, то разработчик будет об это думать и накручивать себя.

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

Также важно знать, сколько времени вы тратите на задачи. Есть программы для учёта времени, например, toggl. Нужно отмечать рабочее время, разделяя на конкретные задачи, важно также отмечать, сколько времени у вас уходит на уточнение задач. Что это даст:

1. Руководителю всегда можно будет показать, сколько времени на какую задачу ушло. Часто для них оказывается сюрпризом, сколько вообще у вас задач и сколько времени уходит на уточнение задач из-за плохих формулировок менеджеров.
2. Можно будет сравнить затраченное время на однотипных задачах. Сейчас, месяц назад, год назад. Если есть рост, значит, вы всё делаете правильно. Если есть рост, то можно и прибавку к зарплате получить.
3. Показывая свой код в профессиональном сообществе, можно сказать: у меня ушло 4 часа, норм? Исходя из ответов делать выводы. Медленно вы работаете или нет. А самое главное понимать — куда расти.

Михаил Адигеев

руководитель отдела программных разработок и поддержки компании «ГЭНДАЛЬФ»

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

На скорость работы влияют, на мой взгляд, два основных фактора (помимо особенностей характера — но тут я ничего не подскажу): а) знания/навыки и б) умение правильно организовать работу над задачей.

Со знаниями/навыками всё понятно — их надо прокачивать (те, которые необходимы для конкретных задач: знание технологий, инструментов, предметной области). Чтобы правильно организовывать работу, надо научиться определять, какие действия нужны для успешного решения конкретной задачи, а какие — избыточны. Выполнение задачи часто затягивается из-за того, что программист делает лишнюю работу из соображений перфекционизма, либо потому, что ему просто нравится «играть» с какими-то инструментами, независимо от их важности для решения задачи. Чтобы избавиться от подобных ситуаций, надо приучиться анализировать задачу и определять, несколько то или иное усовершенствование действительно ценно. И, конечно, интересоваться целями проекта в целом, а не только кодированием.

Артём Михневич

разработчик в kt.team

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

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

Совет junior’ам: оценивайте всегда задачи на 30–40 % больше по времени; если вы перегнете палку, вас просто попросят уменьшить план. Даже для проект-менеджера такой вариант гораздо лучше, чем постоянно напоминать вам о том, что «уже давно должно быть всё готово».

Очень важно помнить о внешней оценке. Считаете, что медленно работаете? Оцените ситуацию со стороны! Если прогресс постепенно идёт, и вы тратите время на решение задачи, поиск лучшего решения, то нет поводов считать себя медленным. В этом особенность и специфика программирования. Здесь не гонки на спорткарах! =)

Итак, как оценить скорость своей работы?

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

В этом деле важно не только быстро стучать по клавишам, но и:

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

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

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

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.