Быстродействие по “Меркелеоновски”

2

«Когда уже будут реализованы оплаченные задачи?».

Такой вопрос мы задавали очень часто, и так же часто получали такой ответ:

«Ваше задание стоит в очереди, вы ведь у нас не одни!»

 

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

 

Но в сотрудничестве с “Merkeleon” быстродействия не возможны. Если сильно упростить процесс разработки, то от идеи до реализации, можно уложить вот в такую схему:

 

1) мы выставляем задание. Обсуждения бывают очень долгими в силу не понимания вопроса аккаунт менеджером Александрой В. или руководителем отдела аукционов Алексеем С. почему для нас надо сделать именно так, а не так как у них уже есть. Своё не знание вопроса они обычно подкрепляют дежурной фразой:

«Поверьте нашему большому опыту в разработках» (следует читать так «Опыту наших клиентов доверивших нам свои наработки»).

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

 

2) оплачиваем. Но в силу того что каждый денежный перевод в австрийскую республику стоит чуть больше €30, приходится копить пакетами доработок а на это уходит очень много времени. Удивительно то, что даже копеечные по стоимости, но важные по значению для проекта задания, не передавались в реализацию до факта оплаты. Но иногда были и такие, которые по ходу формирования счета теряли свою актуальность. Вот пример из переписки с Алексеем С.:

Феликс М.: Алексей, как я уже говорил, что пока вы реализовываете одно (долго) что то становится не актуально. Однако по новым определяться рано, так как старых пере открытых 3, в прогрессе 3. На реализацию этого объема уйдет еще, как я понял не мало времени. Хотя все зависит от вас. Нам нет смысла оплачивать задания, которые реализуются через месяц. Посмотрите сами по статистике. Обозначенные задачи реализовываются неделями. У многих пропадает актуальность и мы отказываемся, но вы утверждаете что если по ним были согласования значит они были в счете и за них надо платить и то что мы отказались то наше желание. как к примеру с этим заданием (MYB-40). У него к стати стоит статус «реализовано». Но мы оба знаем, что это не так, и более того, позже по телефону мы определились что это задание будет выполнено. В общем и целом необходимо подтянуться по текущем делам и потом перейти к новому счету.

 

Алексей С.: Феликс, касаемо будущих доработок сейчас в Jira имеется множество задач с приоритетом 7 и выше. С вашей стороны имеется пожелание о их реализации, поэтому я попросил определиться с планом на ближайший месяц. Вне плана максимально оперативно программиста выделить на доработку не всегда представляется возможным, а дополнительно задерживать реализацию задач мы не хотели бы, т.к. понимаем важность скорости для вас.

Что касается MYB-40, здесь да, вы правы, был отказ по задаче. Можем либо выполнить оговоренный функционал, либо другую задачу на 3 часа сроком.

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

Хорошего вечера!

 

Хорошего вечера? Спасибо за пожелание Алексей. Будет над чем подумать вечером 😉  Я так понял, что если мы не будем платить за новые доработки, то и по старым прогресса ожидать не стоит.

 

3) начало разработки. На этот этап обычно уходит очень много времени. Так как выделение программиста надо спланировать а МЫ У НИХ НЕ ОДНИ и все такое. В общем, каждый новый список доработок, запускал круговорот недопонимания вновь и вновь.

 

4) приемка задания Часто бывало так, что по выверенным на 100500 раз заданиям, результат был диаметрально другим. На первых годах разработки (2013 – 2014) такие задания доделывались без особых пререканий. С поздним периодом становилось всё сложнее хуже. Примеров переписок приводить не буду. Их множество.

 

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

 

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

 

Мы так же практиковали предоплату, но это тоже НЕ ПОМОГЛО!

Пытались объяснить, что плата за тех поддержку практически вся уходит на фикс ранее оплаченных заданий. И то. что надо делать более качественно с первого раза, что бы более активно реализовывать накопившиеся пакеты новых заданий, но ответ был всегда один:

 

«Все в порядке очереди. Вы у нас не одни».

 

И каждый раз мы ожидали своей очереди. А была ли очередь? Много ли они вели проектов? Об этом много и подробно написано вот в этой статье.

Это часть главной статьи «Трёх летнее сотрудничество с компанией SOFTSWISS / MERKELEON обернулось глубоким разочарованием».

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий