# МРМ Приемка

в очередной раз просим предоставить:

* Документацию по Driven Framework
> Документация была предоставлена сразу после того, как был обновлен Driven.framework (27 ноября 2019) и она содержится в самом Driven - Пример участка кода, который отвечате за добавлений действия по заданию:

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

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

Хохлов: нет, не указано. Банально даже "Идентификатор товара" - что писать тут при задачх, где нет товаров? Так или иначе, ответы мы в чате позже получали, я пишу к тому, что то, что вы назвали "предоставлена документация" - это не документация по использованию фреймворка в приложении к разным задачам, это просто сгенерированное описание методов и параметров.

В Driven.framework задокументированы таким образом все публичные переменные и методы.
Пример одного из модулей:

Хохлов: Опять же. Где описание того, что такое например, Action, в приложении к задачам конкреитного МРМ? Что опять же касательно идентификатора товара? Повторюсь - это описание методов, но не описание того, как с ними работать. Примерно как дать техническую документацию на коленвал, поршни и инжектор, но не дать документацию, как из этого собрать двигатель.

Кроме того, примерно с конца декабря у нас есть более подробное [описание работы Driven.framework](http://confluence.moscow.sportmaster.ru/display/MOBDEV/Driven+IOS+SDK)

Только к этой странице у нас не было доступа. А ссылку на нее нам дали в феврале, сами в чати видели. В итоге доступа так и нет.

Все ссылки на Driven.framework опубликованы в пространстве подрядчика:
http://confluence.moscow.sportmaster.ru/display/AMBERLABS/Driven+IOS+SDK

Хохлов: Ссылка на битбакет была всегда, но нас не уведомляют о том, что там публикуются новые версии. Более того, что то, что надо обновить фреймворк, мы обычно узнаем когда что-то перестается работать, тогда возникает идея "А может вы обновили Дривен?", после этого я прошу Анатолия выложить в битбакет, и после мы уже обновляем у себя. Свидительства этого процесса есть в чате. И в один из моих приездов было потрачено время на то, чтобы выяснить, что МРМ не работает из-за того, что новая версия задачника работает с новой версией фреймворка, про которюу нам никто не сказал и в битбакете ее не было.

* Описание алгоритмов работы со статусами задачи и передачи результатов задачи в Задачник
> эта информация была предоставлена 10 сентября 2019 (см. пункт 15 ниже)
>

Хохлов: это описание того, как работает с задачми МУЗ, это выдержка из документа, который описывает МУЗ. В МРМ половины этих статусов не используется, плюс, в этой схеме нет передачи результата.

* Актуальную версию форматов JSON файлов, которые требуется формировать при передаче результатов задач в ваше информационную систему.

> Документация по МУЗ.Приемка была предоставлена 19 июля 2019:


Хохлов: Это формат обмена ДИС и МУЗ. В какие поля что класть при передаче МРМ - Задачник - приходилось докадываться самим.

Внутри документа присутствуют ожидаемые форматы JSON:

Они несколько раз потом менялись, актуальная (которая есть у нас) версия была только в сентябре.

* Утверждение, что заказчик не оказывает помощь не имеет под собой оснований:

Исполнителю предоставлялась вся необходимая информация по работе Driven.framework, МРМ Задачник и взаимодействии их с другими МРМ.
Причем зачастую исполнитель запрашивал информацию в нерабочее время.

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

Примеры оказания помощи:

1. 16 июня 2019 - 

Хохлов: согласен

3. 16 июня 2019 - предоставление архитектуры взаимодействия бэка и мобильных приложений

Хохлов: согласен

3. 16 июня 2019 - Вопрос синхронизации Задачника

Хохлов: согласен, но надо отметить, что задачник - это ваш продукт. Если в нем что-то не работает, это не помощь нам, а исправлением ваших ошибок.

4. 17 июля - 8 августа 2019 - Предоставление доступа к Driven.framework

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

5. 10 августа 2019 - Указание, где лежит **Работа с заданиями (DIS REST API)**, подсказали какой формат, где можно проверить методы, предоставили параметры аутентификации:
6. 29 августа 2019 - Проблемы с получением заданий. В итоге выяснилось, что сами обращались не к тому ресурсу:

Хохлов: по поводу пунктов выше. Артем, мы вообще не должны знать что такое REST API DIS, как к нему обращаться и по какой ссылке. Это никак не входило в скоуп работ. Мы делали это исключительно потому, что Дривен на тот момент не работал должны образом, задачи через него получить мы не могли, и, чтобы хоть как-то работать, мы искали обходные пути. Что касается ссылки - мы обращались по той ссылке, что нам давалм ранее. Почему нам мзначально дали не ту ссылку - вопрос к организации внутри вашей команды. Сами мы выдумать ссылку не могли.

7. 29 августа 2019 - Так как вопросов становилось больше, чем ответом, заказчик предложил встретиться:

Хохлов: верно, потому что приходилось методом тыка делать так, чтобы устройства, предоставленные нам, начали корректно работать и получать задачи. Никакой инструкции по настройке не было, все приходилось выяснять. В том числе про привязку устройств к магазинам - это не скоуп разработки МРМ, разбираться в этой информации приходилось, чтобы запустить работу. Было был здорово на тот момент, если бы вместе с устройствами была передана инструкция - какое прописать имя, как имя устройства связано с магазином, как осуществляется в завичимости от этого синхронизация. Ничего этого не было, все выясняли сами.

8. 20 августа 2019 - Обновление версий фреймворков и новая версия Задачника:
9. 2 сентября 2019 - Предоставление иконки приложения:
10. 3 сентября 2019 - Ответ по формату идентификатора приложения
11. 5 сентября 2019 - Добавление заданий:
12. 6 сентября 2019 - Помощь с bundle id и AppGroup:


13. 8 сентября 2019 (**воскресенье**) - Добавление разработчика подрядчика на портале apple разработки Спортмастер

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

14. 9 сентября 2019 - Предоставление доступа к SMHardware.framework:

Хохлов: Да, только в итоге он переехал в Дривен, из-за чего были конфликты, и о чем я опять случайно узнал у Анатолия. Нам никто не написал "Коллеги, работа с оборудованием теперь в Дривене, хардвейр фреймворк убейте".

15. 10 сентября 2019 - Предоставление документации по статусам заданий:

Хохлов: Ответил выше.

16. 12 сентября 2019 - Ответ по работе в IDE Xcode и взаимодействии со сканером ШК:
17. 12 сентября 2019 - Предоставление документации по SMHardware:

Хохлов: Да, спасибо

18. 10-12 сентября 2019 - Ответ по изменению статуса задания с полным примером рабочего кода:

> 20 сентября 2019 - и еще много вопросов по тому, на что ранее уже был дан ответ.
>
> Складывалось впечатление, что исполнитель не хочет читать код и вникать в то, что там выполняется. По сути в указанном пример нужно было подправить первый кусок кода, который был направлен, и работать с задачами/менять их статус:

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

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

и т.д., в чате "МРМ Приемка" в телеграм очень много вопросов и ответов, в том числе и повторяющихся вопросов.

19. 8 октября 2019 - После перехода на новую версию Driven.framework предоставлена документация по внедрению новой версии Driven.framework, использованию методов авторизации и настройке Keychain :

Хохлов: Да, верно, я приезжал, все с Анатолием сделали.

Вопрос после которого возникает к компетенциям в части iOS разработки:
* 16 июля - любой разработчик с месячным опытом разработки под iOS знает сервис Fabric и как он работает. Амберлабсу для этого действительно нужна инструкция?

Хохлов: Этот вопрос никак не связан с компетеницями в iOS разработке. Сервис Fabric служит для распространения билдов и сбора логов. Разработчик, который пишет тот или иной код, может про него не знать. но, естественно, что есть такой сервис, у нас все знают. Вопрос в том - что никто не сказал, что он есть, и до этого момента билды задачника нам кидали в чат. Письма "Коллеги, мы используем для распространения новых билдов Fabric", не было. Приглашалки в почте потом нашлись в папке спама, к сожалению. Нормальный путь в управлении проектами - ставить в известность подрядчиков относительно путей получения билдов смежных продуктов, тем более, если это этого просто в чат кидали сборки.

Проблемы коммуникации:

1. Находились проблемы там, где их не было - 19-30 июля 2019:

* Просьбы о помощи в нерабочее время:

> как выяснилось дальше проще не стало

* В том числе в выходные:

Хохлов: Да, если мы не можем завести ваш же продукт и у нас не работает выданный нам для этого продукта доступ, это проблема на вашей стороне.

* По любой проблеме подрядчик обращался к нам (получалось не подрядчик занимается написанием приложения, а мы его обслуживаем и на любую сложность он обращается к нам). К определенному моменту это стало сильно напрягать, так как мы выполняли в том числе свою непосредственную работу в Спортмастере:
> И в итоге опять же выяснялось, что проблемы были на стороне исполнителя:
* В дальнейшем в процессе работы выяснилось, что исполнитель не читает высланную по МРМ документацию, где все эти моменты описаны:

Хохлов: Артем, нет! Все эти проблемы были связаны с тем, чтобы в переданном нам задачнике, который делает ваша сторона, на переданных нам устройствах, были задачи, с которыми мы можем работать. Странно, что вы обвиняете в этом нас. Нас совершенно тоже это не устраивало, что большое количество времени ушло на то, чтобы запустить ваш софт, который не в нашей компетенции. То, что код Дривена не видел задачник - это проблема опять же Дривена и Задачника была на тот момент.

Что касается статусов - это опять же были догадки, которые надо было подтвердить (то, как преобразовать статусы МУЗа и статусы МРМ).

* И не видимо не полностью понимает объяснения сотрудников Arcsinus, отвечающих за доработки в части Driven.framework и МРМ Задачник:

Хохлов: вопрос был, насколько я помню, в том, что задачник не синхронизировал справочники. Либо они не приходили. и Кастис это исправлял. То, что до задачника не доходили какие-то справочники - это не компетенция разработчиков МРМ. Плохо, что нам приходилось тратить время на то, чтобы в этом вникать.

* 11 декабря 2019 - К переписке были подключены ключевые исполнители по работам с Driven.framework и МРМ Задачник сотрудники Arcsinus:

> И они в дополнение к уже имеющейся информации подробно расписали как работать с методами Driven.framework

Хохлов: Нет, не расписали. Сами видите, что детали обсуждаются вот сейчас, и Константин же сам писал, что местами ошибался.

* Пример создания лишней работы для iOS разработчиков IT-Driven:

Хохлов: Потому что на тот момент мы не обсудили еще как работать с сертификкатами и были не в курсе вашего процесса девопса. Инстркуции тоже нигде не было. Потом договорились - вопрос закрыли. Это рабочий момент.

* 9 октября 2019 года - не смотря на наличие документации по внедрению новой версии Driven.framework исполнитель так и не смог его установить. С моей стороны было предложено подъехать ко мне перед показом очередной версии МРМ Приемки, чтобы решить проблему:

На встрече я сделал все по инструкции из высланной ранее документации и Driven.framework благополучно был внедрен, а МРМ "Приемка" запущена.

Хохлов: Нет, не так, мы сидели с Анатолием достаточно долго, ровно по инструкции ничего не заработало, на ходу мы смотрели почему не так, и после этого как раз инстркуция была обновлена. Прошу не переворачивать факты, потому что то, что написано выше вами, реально не соответствует действительности. Мы с Анатолием долго разбирались, почему не работает.

Хохлов: Артем, честно не понимаю смысл этого текста. Общая агента простая - на момент, когда мы начали работать, с вашей стороны также велась (и ведется сейчас) активная разработка смежных продуктов, поэтому возникают вот эти моменты. С вашей стороны этот документ был подготовлен с точки зрения "мы вам все дали, вы глупые, ничего не сделали", но это не соответствует действительности. У меня нет претезний, но странно с вашей стороны видеть голословные обвинения в нашу сторону, при том, что вы прекрасно видите, что происходит на проекте и как ведется работа.