Как выбрать хорошего подрядчика для разработки вашего проекта?

5 комментариев
Как выбрать хорошего подрядчика для разработки вашего проекта?
screenshot «Мы специализируемся на предоставлении клиентам профессиональных услуг по разработке программного обеспечения». Такое заявление понравится любому потенциальному клиенту, но увы, любой соискатель-подрядчик позиционирует себя как профессионал. Действительно, если честно признаться в непрофессионализме, то ни к какому проекту вас и близко не подпустят. Но как клиент, обычно не разбирающийся в тонкостях разработки ПО, может убедиться, что подрядчик действительно знает свое дело? Если бы существовал простой ответ на этот вопрос, то можно было бы сэкономить массу денег, которые сегодня тратятся на проекты, с первого дня обреченные на провал. Эта статья предлагает простейший тест на профессионализм, сравнимый с «лакмусовой бумажкой»: в ней перечислен минимальный набор навыков, присущих хорошему разработчику. Неопытный клиент должен ставить перед подрядчиком именно такие вопросы – и он вправе рассчитывать на содержательные ответы. Сразу оговорюсь: я составлял этот список с самыми благими намерениями. Программы можно разрабатывать и при частичном или полном отсутствии этих навыков, и это может быть вполне профессиональная разработка. С другой стороны, даже наличие всего перечисленного не гарантирует триумфального завершения проекта. Итак, допустим, вы – клиент, занятый поиском подходящего подрядчика на разработку программного обеспечения. Для вас это может быть как фрилансер, так и компания. Можете просто вооружиться этим списком и по порядку задать кандидату все вопросы из него. Послушайте, что они ответят, и попросите продемонстрировать те или иные навыки на практике. Поначалу вам вряд ли удастся отличить блестящую реализацию от тривиальной, но постепенно вы научитесь это делать. Суть такова: если разработчик может без труда продемонстрировать тот или иной навык, то, скорее всего, он действительно хорошо им владеет.

Минимальные навыки

Список навыков выстроен в порядке возрастания их непосредственного влияния на качество разработки. Представление о качестве учитывается на трех уровнях: с вашей (клиентской) точки зрения, с точки зрения конечного пользователя и с точки зрения следующего разработчика, который получит исходный код от первого разработчика.

Система управления исходным кодом

Эта техника имеет ряд различных названий: управление исходным кодом (SCM), система контроля версий (RCS или VCS). Она используется для отслеживания любых изменений, вносимых со временем в код. При помощи такого механизма разработчик сможет с точностью узнать, какое изменение и когда было внесено в код, в какой версии это произошло и кто это сделал. Позже такое изменение даже можно отменить. Если ваш собеседник говорит, что имеет опыт работы с конкретными инструментами контроля версий – например, Git, Subversion, Perforce или Mercurial, то этот вопрос можно считать решенным. Предложите подрядчику продемонстрировать типичный цикл «синхронизации-редактирования-правки» и попытайтесь понять, что он вам говорит. Большинство разработчиков любит хвастаться своими мастерскими навыками работы с системами контроля версий.

Отслеживание задач

Система отслеживания задач (а также отслеживания ошибок) – это инструмент, сохраняющий все запросы, отчеты об ошибках, пожелания и жалобы, которые вы вносите. Его можно сравнить со справочной системой «талонов о неисправностях» (trouble tickets). Система отслеживания задач предоставляет разработчику своеобразный «план действий» и выступает в качестве объективной документации вашего общения с разработчиком. Если вы не можете получить прямой доступ к системе отслеживания задач на сайте, предложите кандидату продемонстрировать типичный сценарий – например, составить отчет об ошибке. Как минимум, разработчик должен предоставлять вам список решенных проблем по каждой версии вашего ПО.

Непрерывная интеграция

Это сравнительно новый инструмент, обладающий, однако, значительным потенциалом. Его также можно назвать «сервером сборки приложений» (build server). Также говорят о «ночной сборке» (nightly build). Мы исходим из того, что сборка вашего проекта будет автоматизироваться, когда это только возможно. В случае непрерывной интеграции новая сборка происходит после каждой отправки новой порции исходного кода в систему контроля версий (о ней мы говорили в первом пункте нашего списка). Попросите разработчика продемонстрировать, что происходит автоматически после отправки кода в систему контроля версий. Спросите кандидата о «времени сборки» вашего проекта (или других проектов). Время сборки – это период, необходимый для получения новой версии, которую вы сможете протестировать. Если время сборки довольно невелико (скажем, несколько минут) – попросите внести в проект небольшое изменение и дождитесь результата. Вполне возможно, что ваш разработчик затронет не только тему «непрерывной интеграции», но и «непрерывного развертывания». Всплывут вопросы, связанные с «подготовкой файлов» (staging), «очередью сборки» (build queue), «тестовой установкой» (test installation) и т.д. Вот и отлично! Дайте ему возможность продемонстрировать «непрерывное развертывание» на практике. Вы, вероятно, будете впечатлены, а разработчик получит еще один шанс козырнуть перед вами..

Верификация (она же тестирование)

«Будут ли в исходном коде содержаться автоматизированные тесты?» – о, это вопрос деликатный. В нашем деле ожидаемая ценность каких-либо автоматизированных тестов по-прежнему стремится к абсолютному нулю. Но, если в ответ на этот вопрос кандидат просто недоуменно воззрится на вас – это плохой знак. В случае содержательного ответа не так важно, будут ли упомянуты «модульные тесты», «интеграционные тесты» и даже «приемочные тесты». Важнее другое: пусть кандидат продемонстрирует вам реализацию автоматических тестов в вашем (или подобном вашему) проекте. Убедитесь, что сервер непрерывной интеграции (подробнее о нем – в третьем пункте) действительно осуществляет автоматизированные тесты, причем при каждой сборке. Таким образом, если откажет любой компонент, подкрепленный тестами, то вы об этом сразу же узнаете, и вам не придется сталкиваться с ошибками, которые вновь и вновь появляются в каждой следующей версии (такой симптом называется «регрессия»). Возможно, ваш разработчик окажется настоящим энтузиастом тестирования. И пусть каждый час его труда стоит немалых денег – не сомневайтесь, что деньги на тестирование тратятся не зря. Считайте, что этим вы перестраховываетесь от любого неожиданного поведения вашей программы в будущем. В ходе разработки сами тесты, скорее всего, будут незаметны, поскольку они используются внутрисистемно. Попросите разработчика рассказать о том, как он организует отчетность о тестировании. Может быть, составляется отчет о «тестовом покрытии», сопровождающий список задач (такой список рассмотрен во втором пункте)? Если специалист утверждает, что практикует «разработку через тестирование» (test-driven development) – можете быть уверены, что он старается проводить максимально детализированные тесты. Позвольте ему продемонстрировать вам достоинства такого подхода и смоделируйте цикл реализации небольшого изменения в вашем проекте. Возможно, это убедит вас в полезности подобной перестраховки.

Документация по проекту

Все софтверные проекты, кроме самых элементарных, содержат такую массу деталей, что человек просто не в состоянии запомнить их все, и рано или поздно что-то забывает. Ваш разработчик должен иметь некоторый практический опыт хранения информации о проекте, не только «в коде» и «в системе отслеживания задач». Популярным вариантом реализации этого требования является документирование проекта в wiki-форме – именно в такой форме написана всем известная Википедия. Задумайтесь о возможности использования онлайнового текстового редактора с функциями структурирования информации. Если у вас нет доступа к самому инструменту документирования, попросите разработчика продемонстрировать его на практике. Попросите выдержку из документации по вашему проекту, например, в формате PDF или HTML. Не придирайтесь к эстетическим сторонам документа, основные его качества должны быть – удобство и простота поиска нужной информации. В конце концов, подойдет даже рукописная документация, если она в порядке и хранится в одном определенном месте.

Соглашения в исходном коде

Практически любой исходный код является машинно-читаемым. Но встречаются такие образчики кода, которые совершенно нечитабельны для коллеги-программиста, а то и для самого автора. Расспросите разработчика о том, какие правила форматирования кода он применяет. Возможно, он действительно представит вам письменные правила, реально применяемые при создании кода. В большинстве языков программирования есть инструменты, позволяющие проверять форматирование на соответствие определенным правилам. Такие программы называются «инструментами для инспекции кода» и идеально подходят для работы с сервером непрерывной интеграции (см. третий пункт). Правда, некоторые аспекты читабельности исходного кода нельзя проверить алгоритмически – скажем, выбор имен или ясность концепций. Хорошие разработчики регулярно инспектируют код, критически обсуждая его с коллегами и предлагая варианты оптимизации. А хороший клиент открыто указывает на необходимость code review, даже если сам не собирается в ней участвовать. В долгосрочной перспективе вы скоро сами убедитесь, насколько от этого улучшается качество программ.

Участие в жизни сообщества

Разработка программ – это стремительно развивающаяся сфера деятельности, в которой то и дело происходят судьбоносные открытия – не реже, чем раз в год или два года. Отдельно взятый разработчик не может отслеживать развитие всех непрерывно изменяющихся инструментов, феноменов и возможностей в сфере своей профессиональной деятельности. Приходится полагаться на опыт сообщества коллег и единомышленников, а также опытных экспертов, готовых делиться своими знаниями. Спросите разработчика, как он взаимодействует с сообществом коллег. Какие (технические) книги он недавно прочитал? Какие книги изучены всей командой разработчиков? Вы как клиент, пожалуй, не сможете сразу оценить, насколько ценны названные разработчиком книги, но это и не самое важное. Как и в случае с тестами, список книг, прочитанных средним программистом, может и не быть слишком велик. Важно, что команда разработчиков является достаточно сплоченной и обладает общей базой технических знаний, почерпнутых в специальной литературе. Но и книгами дело не ограничивается. Ведь печатные книги просто не успевают за развитием отрасли! Спросите о том, в каких технических конференциях участвует кандидат, а также состоит ли он в пользовательских группах по обсуждению языка программирования, используемого в вашем проекте. Как организована совместная работа? Любит ли разработчик делиться своим опытом и находками? Кстати, для этого достаточно просто вести свой блог (например, такой, как вы сейчас читаете). Попросите программиста показать вам свой блог. Сколько статей он опубликовал за определенный промежуток времени, каков отклик на них? Может быть, ваш кандидат пишет статьи для специального журнала или даже работает над книгой? А теперь можно будет и поинтересоваться у других разработчиков их мнением об опубликованных материалах. Возможно, вы нашли настоящего профессионала – остается вас только поздравить! .

Но и это еще не все, далеко не все...

Этот список не исчерпывает всех тех навыков, концепций и инструментов, с которыми должен уметь работать хороший специалист. Это всего лишь минимальный набор, который можно и нужно дополнять и улучшать. Существуют целые комплексы навыков, такие, как «разработка чистого кода», – обо всем невозможно упомянуть. Спросите о том, что интересно самому разработчику. Будем надеяться, его уместное бахвальство и профессиональный сленг быстро убедят вас, что вы действительно имеете дело с профессионалом. А меньшим довольствоваться и не следует. ИСТОЧНИК

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая

Конкурс EY Entrepreneur Of The Year 2020

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

Notion снял ограничения в бесплатном тарифе
Notion снял ограничения в бесплатном тарифе

Notion снял ограничения в бесплатном тарифе

2 комментария
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19
Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

2 комментария
А1 и чешский техностартап с офисом в Минске запустили систему умного дома
А1 и чешский техностартап с офисом в Минске запустили систему умного дома

А1 и чешский техностартап с офисом в Минске запустили систему умного дома

1 комментарий

Обсуждение

0

Вот после таких статей клиент и начинает голову дурить... если он не понимает что и как то и не надо этих гайдов "Весь процесс разработки за 15 мин"

1

А выберут в итоге все равно тех которые дешевле!!!

0

*

1

Очередная мутная статейка от некоего internet :-) Собственно, всё дело в том, что любой уважающий себя фрилансер или аутсорсинговая контора готовы навешать вам лапши о своих крутых процессах, а настоящие кадры проверяются только на практике.
Эти советы похожего плана, как перед покупкой авто, убедитесь в том, что на него дают гарантию, у него есть ABS и гидроусилитель руля. Так это всё есть и в Бентли и в каком-нибудь китайце. Только стоят почему-то по разному.

-1

Я бизнес! Я не хочу разбираться в ИТ, я хочу делать деньги!
Что б я о чём-нибудь из этого спрашивал своего разработчика??? Мне, как заказчику, совершенно параллельно, какими системами управления кода разработчик пользуется, как отслеживает задачи и как тестирует. Мне важен итог. Мне важно ЧТО будет в итоге. Вопрос КАК этот итог будет достигаться, это сугубо проблемы разработчика. Все технологии, все инструменты, это всё его трудности. Есть бюджет, есть требования, есть время. Меня интересует исключительно результат! Головную боль о пути его достижения разработчик может оставить себе. Мне хватает своих "головняков" о моих делах. В конце концов, он же не учит меня, как вести бизнес. Вот и я не пытаюсь учить его разработке. Будет у него там автоматизированное тестирование и контроль версий или сорок негров тестировать будут, а сорок индусов путаться в "винегрете" из кода разного уровня "свежести", какое мне до этого дело?
Или я ещё буду спрашивать, какие он книжки читает и конференции посещает? Вообще финиш полный. Может он с женами ведущих персон в ИТ спит, оттуда все новости и узнает. Может ему так удобней, мне то какая разница.
Одна "подружка" готовит в крутейшей очень дорогой пароварке только из самых дорогих изысканных ингредиентов по новейшим рецептам, подписана на пять кулинарных журналов, ни одно кулинарное шоу на ТВ не пропускает. Готовит постную дрянь, которую есть невозможно. Ну и что толку, что очень долго парням про свою пароварку и рецепты рассказывает, всё равно второй раз на ужин уже никто не приходит. Так мало того, расстраивается, думает купить ещё более крутую пароварку и подписаться на шестой журнал. Вторая "подружка" на обыкновенной чугунной сковородке так простые драники пожарит - оближешься. И без долгих рассказов, что и как она делает. Да и расспрашивать зачем, вкусно же, какие ещё нужны доводы. Так что решает ни наличие крутой пароварки, ни даже уменье ей пользоваться. Если заказчик разбирается в кулинарии он может обсудить всю эту "кухню", но это совершенно не обязательно. Решает одно - уменье удовлетворять желания заказчика, предоставить ему в итоге "вкусное блюдо". Всё остальное попросту лишнее.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже