Проблемы с заказчиком при разработке мобильного приложения

Sergej Maslo Product Manager в kit/code 10.12.2014 13:16

Разбираемся в ситуации:

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

Надо понять, с кем вы общаетесь на стороне заказчика?
С таким же прожектом которого взяли за мягкие места или непосредственно с владельцем компании. Прожект переживает за свой про*б, владелец что его продукт будет уныл/не крут/не окупится, если тень будет светлее.
(Важно понимать: прожект так или иначе итшник и понимает о чем вы говорите и просто не смог/побоялся объяснить все своему работодателю. А владелец ведет другой бизнес и ему до лампочки что кастомное будет дороже или дольше, ему важно выполнение поставленной перед апликухой своей бизнес-задачи, не более.)
Если с прожектом, переходите на уровень выше, если с владельцем, объясните ему что данное решение более успешное, чем то которое было заложено его дизайнером. Вы все таки профессионал и знаете как лучше.

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

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

Шаг #2. Разговор с заказчиком и командой.

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

Dmytro Zemnytskyi Засновник в Pragmasoft, Харків 10.12.2014 13:08

Думаю что основная проблема с Вашей стороны вот в чем. Сначала вы пишете:

мы только что закончили небольшой проект

Потом пишете

Оценка команды на полировку приложения + тестирование + отправку разработанной программы = 3 рабочих дня.

То есть, на самом деле, проект НЕ БЫЛ закончен. Сначала Вы пытались сдать неоттестированный и незаконченный проект, в надежде, что и так прокатит, а когда не получилось, признали его незаконченным и потребовали еще 3 дня. Это реально возмутило заказчика.

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

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

Dmytro Zemnytskyi Засновник в Pragmasoft, Харків 10.12.2014 13:07

Думаю что основная проблема с Вашей стороны вот в чем. Сначала вы пишете:

мы только что закончили небольшой проект

Потом пишете

Оценка команды на полировку приложения + тестирование + отправку разработанной программы = 3 рабочих дня.

То есть, на самом деле, проект НЕ БЫЛ закончен. Сначала Вы пытались сдать неоттестированный и незаконченный проект, в надежде, что и так прокатит, а когда не получилось, признали его незаконченным и потребовали еще 3 дня. Это реально возмутило заказчика.

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

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

Ivan Dmytriiev Измеряю длину шеи жирафа и ширину ноздрей бегемота в этих ваших аутсорсах 10.12.2014 13:04

только что закончили небольшой проект

Что подразумевается под «закончили» срок контракта или объем выполненных работ?

приложении полно багов

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

дизайнер со стороны заказчика не обращал внимание на качество

Сделайте в полном соответствии с мокапами заказчика , и все последующие вопросы будут именно к тому самому дизайнеру.

программно невозможно повторить на 100% нарисованную в дизайне тень

Ваш бок, если не обсудили этот вопрос на коллах с заказчиком.

Еще 20% — это баги разработки

Если сроки поджимают — отсортируйте по критичности , и пофиксите только самые важные баги. Опять таки цифра 20% очень расплывчатая (20% при общем колличестве багов 1000 это довольно таки дофига:))

как корректно ответить заказчику и убедить его, что нам нужно 3 дня

Используя много красивых речевых оборотов:) Сказать что такой факап произошел впервые, чисто случайно по ужасному стечению обстоятельств . Сказать что у QA лида заболела кошка, что девелоперы отравились сыром, а дизайнер купил новую зеркалку и развлекался по полной:) И вследствии всего этого Вам остается только переделать все хорошо (заинвойсить этот процесс, опять таки в зависимости от контракта) и выслать ему готовый идеальный билд через 3 дня.)

Viacheslav Titov Mobile Fullstack Software Developer (Android, IOS, Flutter, React-Native) в Agiliway 10.12.2014 12:24

дизайн не соответствует psd-файлам

Заказчик прав. Так как ему на картинке показали одно, а вы сделали другое. Даже если кнопка одна в разных активити отличается размерами а вы сделали одним то виноваты вы. Делайте все в точь как на дизайне и тогда если заказчик будет придираться вы в лицо ему дизайн с визгом что он сам заапрувил такой дизайн. И вы наверное небрежно отнеслись к дизайну. Нужно проверять все до мелочей. Если что то не соответствует официальным гайдлайнам то сразу стучим заказчику и прежупреждаем. Если есть какие то трудности с реализацией такого дизайна тоже стучим заказчику и пускай меняет дизайн или увеличиваете эстимейт.
P.S. Нормального дизайна для мобильных платформ найти очень трудно. Рисуют они замечательно, но гайдлайны не знают. У меня дизайнер на последнем проекте все перерисовывал по 3-4 раза, вплоть до каждого пикселя.
P.P.S. Если заказчик берет линейку и не хватает хотя бы одного пикселя в приложении то опять таки виноваты вы. Я уже наступал на такие грабли. Реально брали скриншот с приложения и в фотошопе сравнивали дизайн и скрин с приложения и по пикселям сравнивали.

anonymous 10.12.2014 07:34

-

Roman Brunets Программист в контрактор 09.12.2014 21:38

Напишите ему гневный ответ, что у заказчика в голове полно тараканов, график оплат не соответствует договору и вообще цены на нефть упали, а ценник остался тем же. Потребуйте нового транша оплаты в размере 30% стоимости проекта завтра вечером. :) И вообще, вы ему очень соболезнуете, но религия, устав вашей компании и здравый смысл прямо запрещают вам работать бесплатно. ;)

ЗЫ Чего вы паритесь? Ну наругали его акционеры, он на вас злость сорвал. Не думаю, что он всерьез считает, что вы будете работать бесплатно.

Oleg Kariakin Senior Java Developer 09.12.2014 20:59

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

Alexey Tsymbal CMO в MobiDev 10.12.2014 12:32

Лично для меня фраза, что личное мнение\настроение влияет на оценку — капитанство. Каждый менеджер (в любой сфере) пытается минимизировать такое влияние (сделать его осознанным), однако только единицам действительно профи это удается... — это офтоп

по теме: Вы совершенно правы: в этом кейсе мы смотрим и на формальную сторону: что предлагает кандидат; и на то — как он это предлагает\в какой форме\стиле\манере...

Oleg Kariakin

Oleg Kariakin Senior Java Developer 10.12.2014 15:05

Я о том, что правильного ответа (-ов) не существует и любой ответ соискателя может трактоваться в любую сторону от гениальности до абсурда, что зависит от собеседующего лица. И мне как технарю это тяжело понять, наверное стресс-интервью уходят в прошлое.

Alexey Tsymbal CMO в MobiDev 09.12.2014 20:02

О! Круто :) Кейс из нашего тестового задания... придется менять и придумывать что-то новенькое.
Для справки: этот кейс используется (уже: использовался) компанией MobiDev в тестовом задании. Это смоделированная сложная ситуация для кандидата. Так сказать: все факапы в одном флаконе.

Искренне верю (ибо верю в людей), что тут нет цели выполнить тестовое, скорее есть интерес соотнести свое виденье с мнением общественности. Так что все ок :)

Алексей, HR GroupLeader MobiDev

Sergii Voloshyn Product Manager в DOU.ua 09.12.2014 21:01

Вот тут еще похожее обсуждение:
www.e-xecutive.ru/.../message373897

Alex self employed 09.12.2014 21:14

А можно линк на задание, интересно жеж

Alexey Tsymbal CMO в MobiDev 10.12.2014 12:43

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

Alex

Temko Komissarov PM in Travel в DataArt 10.12.2014 14:50

А коли не секрет на какую позицию задания такого плана?)

Alexey Tsymbal CMO в MobiDev 10.12.2014 18:38

На позиции в направлении Project management и Client care management.

Temko Komissarov

Temko Komissarov PM in Travel в DataArt 10.12.2014 19:58

Ааа, спасибо, всегда было интересно как ПМ-ов собеседуют) а для Куа лидов что то подобное или совершенно другой набор ситуаций/вопросов?

Alexey Tsymbal CMO в MobiDev 10.12.2014 20:25

ИМХО: тестовые задания для кандидатов с профильным для вакансии опытом не имеет смысла давать домой. К тому же, это некоторое неуважение к кандидату: у вас опыт КУА лид 5 годов, нате сделайте тестовое — я б не делал!

А без профильного (специализированного) опыта приглашать кандидатов на Лид позиции — как-то....

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

Есть еще случаи очень специфических вакансий(проектов), где нужны очень узкие знания\умения, но это отдельно.

Тестовые, которые даются непосредственно во время встречи — это уже другая история и тому же КУА лиду на встрече можно предложить обсудить пару кейсов как из технической сферы, так и из менеджмента.

Temko Komissarov

Temko Komissarov PM in Travel в DataArt 11.12.2014 00:13

Спасибо за ответы с вами приятно общаться!