Личный опыт Crayon Bunch
323

Проверяем разработчика на профпригодность в XXI веке

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

В закладки
так выглядит профпригодность

Поговорим о непредсказуемости заказной разработки. Можно ли ее избежать?

Непредсказуемость связывают с мнимым отсутствием ограничений при разработке с нуля. Для разработчика это, с одной стороны, плюс – можно реализовать самые смелые мечты –, с другой стороны, риск – риск уйти не туда или поддаться соблазну создать продукт на все случаи жизни. Соблазн заразен, и финансовая свобода заказчика в этом случае – негативный фактор. Поэтому обеспечение предсказуемости разработки – это не только головная боль заказчика, но и первичная организационная задача команды разработки.

Что может сделать команда разработки, чтобы всем было спокойно?

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

Есть другой вариант – формировать дорожную карту продукта итерациями. Тот самый agile, который прекрасно работает, если финальный результат пока не понятен. Быстро создать MVP (минимальную базовую версию продукта), протестировать ее на реальных пользователях, и наращивать разработку и функциональность на основе полученной обратной связи.

Как проверить, есть ли у разработчика эти самые рамки до того, как подпишешь контракт?

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

Если он владеет широким стеком технологий, которые можно использовать, и может обосновать выбор тех или иных технологий, то это второй положительный маркер.

Если он задает вопросы, может сформулировать ТЗ и «дорожную карту» проекта до подписания договора – это третий положительный маркер.

Если он озаботился интеграцией решения на старте, это четвертый маркер. Потому что сама разработка — только часть работы (не всегда бОльшая). Основная задача – состыковать получившееся решение с имеющейся у заказчика инфраструктурой. А зачастую, не только с подсистемами заказчика. И вот здесь заказная разработка однозначно выгоднее во всех смыслах. Понимая, что и с чем предстоит интегрировать, это закладывается в продукт на старте. Тогда как используя готовое решение, приходится изощряться, так как возможности коробочного продукта ограничены. В таких случаях интеграционная часть работ выходит легче и дешевле, чем при кастомизации.

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

Тут есть два нюанса. Во-первых, гибкие методологии разработки – не про отсутствие границ в принципе. Они про ситуации, когда и разработчик, и заказчик понимают, что на каком-то этапе это процесс не прогнозируем. И они оба с этим прогнозируемо согласны. Непрогнозируемость строго очерчена. Поэтому результат все же может быть сформулирован в том или ином виде.

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

Какие компетенции в итоге являются ключевыми для команды разработки?

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

Приведу пример. У нас был проект по автоматизации управления платными автомобильными трассами. Мы, как разработчики программной части, должны были обеспечить управление дорожными устройствами – светофорами, шлагбаумами и др. – с помощью нашего ПО. Но на момент финального этапа разработки строительство самой дороги было не закончено, и дорожных устройств у заказчика, а значит, и у нас, не оказалось. Было два пути. Ждать окончания строительства, и тогда ввод трассы в эксплуатацию был бы сдвинут в том числе потому, что заказчику после получения оборудования нужно было бы ждать, когда мы интегрируем свой софт с устройствами. Или же решить вопрос оперативно.

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

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

#интервью #разработка #управление_проектами

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Crayon Bunch", "author_type": "self", "tags": ["\u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435_\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u0438\u043d\u0442\u0435\u0440\u0432\u044c\u044e"], "comments": 4, "likes": 0, "favorites": 8, "is_advertisement": false, "subsite_label": "life", "id": 45397, "is_wide": false }
00
дни
00
часы
00
мин
00
сек
(function(){ var banner = document.querySelector('.teaserSberbank'); var isAdsDisabled = document.querySelector('noad'); if (!isAdsDisabled){ var countdownTimer = null; var timerItem = document.querySelectorAll('[data-sber-timer]'); var seconds = parseInt('15395' + '50799') - now(); function now(){ return Math.round(new Date().getTime()/1000.0); } function timer() { var days = Math.floor(seconds / 24 / 60 / 60); var hoursLeft = Math.floor((seconds) - (days * 86400)); var hours = Math.floor(hoursLeft / 3600); var minutesLeft = Math.floor((hoursLeft) - (hours * 3600)); var minutes = Math.floor(minutesLeft / 60); var remainingSeconds = seconds % 60; if (days < 10) days = '0' + days; if (hours < 10) hours = '0' + hours; if (minutes < 10) minutes = '0' + minutes; if (remainingSeconds < 10) remainingSeconds = '0' + remainingSeconds; if (seconds <= 0) { clearInterval(countdownTimer); } else { timerItem[0].textContent = days; timerItem[1].textContent = hours; timerItem[2].textContent = minutes; timerItem[3].textContent = remainingSeconds; seconds -= 1; } } timer(); countdownTimer = setInterval(timer, 1000); } else { banner.style.display = 'none'; } })();
{ "id": 45397, "author_id": 201332, "diff_limit": 1000, "urls": {"diff":"\/comments\/45397\/get","add":"\/comments\/45397\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/45397"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123 }

4 комментария 4 комм.

Популярные

По порядку

2

Ни на один поставленный вопрос, не дан внятный ответ. От статьи сложилось впечатление, что на вопросы отвечал юрист, а не инженер.

Ответить
1

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

Ответить
1

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

Ответить
1

Хороший жизненный пример с трассами.

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

Хорошо, что в этом случае всё кончилось хорошо.

Ответить

Комментарий удален

0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления