История одного стартапа (из прошлого)

Мои друзья часто называют меня ворчуном. Коллеги называют меня очень придирчивым и требовательным. Я же считаю что мои действия почти всегда опираются на логику и «я за правоту». Хотел рассказать историю своего участия в одном «большом» международном стартапе в торшинском стиле, но понял что матами тут вряд ли что получится грамотно рассказать, да и не нужны они, ведь как говаривала моя мама «надо быть на голову выше». К этому я и стремлюсь. Есть еще один нюанс — это контракт в 15 страниц по которому я даже словом обмолвится не должен. По сему так и будет. Никаких имён, никаких названий. Только сокращения и никаких разоблачений для юридической и моральной чистоты, но кто знает или догадается, тот молодец.

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

1) Вступление

2) Действующие лица

3) Подготовка к работе

4) Рабочие процессы

5) Финал


6) После финала

7) Вывод и немного о себе

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

Вступление (1)

Летом 2016 года, я ушел из проекта Aviakassa.ru, скатался отдохнуть с женой в Грузию и вернулся чтобы начать поиски работы. Целью был всё тот же travel сегмент и желание делать отличные продукты. Тогда-то в офисе на одной из встреч я познакомился с основателем стартапа (далее Ф. — прим.автора), который послушал мои сладострастные и прямолинейные речи и изъявил желание «забрать» меня в свой продукт. Это было здорово, человек сделавший отличный продукт и компанию, решил позвать меня делать не менее интересный продукт с нуля для международного рынка. Мы списались в Facebook и он обещал вернуться в течении 7-8 дней с предложением. На тот момент у меня уже было около 7 встреч, пара предложений о работе, я подождал немного и не получив возвращения к беседе, согласился на предложения одного большого медиа-холдинга.

Так прошло 6+ месяцев, проект был близок к закрытию и я по собственному желанию его покинул. Первые две недели я просто отдыхал, встречался с друзьями, играл в BF1 и сидел в Facebook. Что самое главное для меня — я начал вести этот блог снова и уже намеренно писать хотя бы раз в неделю. Вторую неделю я провел в общении с компаниями из Питера и Москвы, встречи, обсуждения. Большая часть их компаний хотела бы работать со мной, но на данном отрезке времени не готова сделать офер. Остальные отчасти мне не нравились или нравились, но я не понимал как сменить профиль с tavel на что-то другое.

Но, в один прекрасный вечер, френд прилетел из-за границы, мы встретились как обычно и за пивом начали обсуждать привычные дела. Его компанию и развитие. Моё будущее и взгляды. Он предложил снова сойтись в беседе с основателем Ф., на что я согласился, ведь второй раз такой шанс выпадает очень редко, да и тема travel мне очень близка. Так началось наше «активное» общение. Пару дней мы рывками (наверно потому что основатель Ф. очень занят) общались в Facebook и потом договорились о встрече, чтобы всё обсудить. На тот момент я знал что проект начал свою жизнь еще в августе 2015 года, активная стадия разработки мобильного приложения началась в июне 2016 и вот-вот должен был быть релиз (как я помню его обещали в сентябре 2016), но этого всё время не случалось, поэтому основателю Ф. потребовались разработчики (их у меня два и оба отличные) и руководитель.

Мы получили доступы к приложению для изучения, частично осознали что там мягко говоря не всё ок, рассказали это основателю сервиса и договорились о стоимости наших услуг. Хочу сразу заметить, что не смотря на амбициозные задачи и цели сервиса, команда работает частично удалённо, частично в коворкинге, в котором удобно бывать основателю, а не команде (личное наблюдение) так как вещи свои оставить нельзя, вокруг ходят люди и не понятно что происходит. Коворкинг кстати не самый известный, а точнее самый неизвестный многим. Но тут уже надо писать следующие главы.

Действующие лица (2)

Дабы не увеличивать этот пункт, опишу кратко о каждом персонаже и предлагаю попробовать запомнить всех, но если это сложно, вы всегда сможете вернуться и подсмотреть ху из ху.
А. — автор сего рассказа. Вероятно очень сильный трудоголик, так как большую часть времени проводит за компом, за задачами и проектами которые у него есть. Если таких нет, начинает безумно страдать и впадает в депрессию.
Б. — менеджер контролировавший разработку мобильного приложения сервиса. Так же является менеджер направления cars.
В. — до момента пока Б. не взял на себя обязанности рулить мобильным направлением, вёл его, Так же как и Б. отвечает за определённое направление в сервиса, т. е. hotels.
О. — я мало общался с этим парнем, но по мне он достаточно адекватен. Не всё с его стороны было сделано в сервисе правильно, так же он являлся менеджером направления avia.
П. — собственно главное действующее лицо рассказа. Он основал одну большую известную компанию. Был смещен с управленческой должности и решил открыть новый сервис. Вроде как уважаемый человек в travel, человек «слова» и действия.
С. — один хороший специалист по QA, который за 5 минут нашел в приложении больше 20 багов и логических ошибок.
Ф. — международный проект, основанный в августе 2015 года. По понятным причинам ввиду странного 15-ти страничного договора, я не могу назвать настоящим именем, могу лишь только сказать что проект travel и его основной цвет — это фиолетовый.

Подготовка к работе (3)

Финально мы встретились с П. в середине марта 2017 года, где обсудили задачи, ежемесячные компенсации и условия. В общем-то тут всё банально. Около 2х недель я говорил «ок», на просьбы П. подождать, потому что он утрясает все вопросы, но работать надо-надо-надо. Прошло две недели и я получил письмо от коллег П. (видимо юристы) с американской стороны с запросами данных счетов для перевода денег, данных паспорта для указания в контракте. Окей, мы с ребятами всё выслали и стали ждать. В Конце марта пришло письмо с тремя контрактами оформленными с 01 апреля 2017 сроком на 2 месяца. А-ля испытательный срок. П. выражал большую уверенность что всё будет ок и контракты мы продолжим.

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

**Hi A,
Thank you for your patience. Please find attached the three requested agreements.
After approving the agreements, you can each sign the final page of each document, send a good quality scan of this page to > us, and we will send you a completed version of each document with P. signature.
Thank you,**

Так как контракты были оформлены 01 апреля, а их (контракты — прим. автора) мы получили днём 30 марта, то мы оперативненько с ними ознакомились, были пару вопросов, но больше от незнания американского права и подписанные листы были отправлены 31 марта. после этого о нас забыли, никаких документов подтверждающих работу так и не пришло никому из нас на почту. Но ведь нельзя не верить Уважаемому П., вроде как его слово — это слово достойного опытногонастоящего руководителя подкреплённое его авторитетом. Мы верили и верим до сих пор.
Еще мы попросили предоставить нам информацию об инструментарии на проекте. П. переадресовал эту просьбу Б. который по его словам был типо СТО. Мы получили списочек:

Коммуникации

slack — коммуникации по рабочим вопросам

zoom — групповые звонки

email — нотификации

telegram — коммуникации по нерабочим вопросам


Управление

jira — таск треккер

tempo (плагин в jira) — логирование времени

google calendar — планирование групповых звонков, фиксация нерабочих дней (заболел, взял отгул и тд)

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

confluence — внутренняя вики

swagger — UI к API

postman — коллекции запросов к API


Дизайн

sketch — просмотр макетов UI


Аналитика и мониторинг

amplitude — события с клиентских приложений (ios, web)

sentry — ошибки серверных приложений

crashlytics — крэш репорты

Разработка

bitbucket — исходный код проекта


О! Круто! подумал я, ребята подошли с толком к делу, сразу всё сделали, всё подготовили. Ну ок, а что было в действительности? Следующая глава.

Рабочие процессы (4)

Теперь надо подробно рассказать об инструментарии и его использовании. Чуть дальше о работе и что же происходило во время. Почему я решил написать этот рассказ.

Коммуникации

Slack — использовался командой по назначению для решения вопросов во время работы. Для небольшого проекта, было создано (изначально и в процессе) около 40 каналов, хотя максимально использовалось всего штук 6. Ни в один из канал не падали никакие уведомления от используемых сервисов. Мы в первый же день работы, вынесли мобильную команду в отдельный чат, добавили туда несколько разработчиков бэка и подключили уведомления от crashlytics. Просто пестня, ведь не всегда почта под рукой, а вот slack всегда.

Zoom — это видимо фетиш такой по американским технологиям, когда нельзя созвониться в slack ( на самом деле можно), когда нельзя созвониться в skype (на самом деле можно), а надо использовать специальный сервис. Кстати был веселый случай с этим zoom. Если вы не пользовались, то вам требуется или установить приложение или запустить его на сайте. Чтобы подключиться к беседе вам надо перейти по сгенерированной ссылке от одного из участников беседы и разговаривать. Так вот, такая ссылка отправляется узкому кругу людей, раз в неделю и там обсуждается всё что сделано за прошедшие 7 дней. В одну из таких бесед попал неизвестный и никто до сих пор не знает как так получилось. Только после того, как на нем через 20 минут разговора было акцентировано внимание, он вышел из чата. Секурность чокаво. И да, звонки случались либо в 9, либо в 10 вечера... Ну вы поняли, рабочий день 8 часов... Я не против, просто в это время я еще был в «офисе»

email — нуууууууу, я на него только получал приглашение в zoom и письма от сторонних разработчиков.

telegram — имея слак, почту, zoom, на самом деле рабочие процессы между П. и всеми менеджерами проходили в этом мессенджере. Там могли появляться сообщения глубокой ночью требующие моментальный ответ. Я не против. Но есть же слак, почта, zoom.

Управление
Jira — не сильно люблю любил все эти таск-менеджеры до прихода в Ф. Почему полюбил? Потому что зайдя в него я понял что там творится лютый адок. Все, абсолютно все задачи сбросаны в один проект.... Тоесть в Ф. есть три основных направления и пару фич — avia, hotels, cars, profile. Еще есть и планировалось два — iOs & Android. Всё это было в одном проекте. Тоесть понимаете какая неразбериха была с нашим приходом.

Мы попросили Б. вынести все таски iOs продукта в отдельный проект в первый же день. Тем самым осознали объёмы работ, ведь начались работы с 3-го апреля и дедлайн был установлен на 28-е апреля. Один рабочий месяц. И около 120 тасков... Тасков с багами от мало до велика, тасков с допиливанием и интегрированием логики, тасков с изменением и доработкой дизайна. Всё это легло на плечи 2,5 разработчиков (один же парттайм) и одного менеджера.

Засучив рукава принялись работать. Конечно же изначально требовалось расставить приоритеты по таскам, чтобы понимать что можно сделать быстро, что нужно сделать важнее чем быстро, раскидать это всё по разработчикам и начать процесс. Дело сделано. У всех теперь есть понимание что же делать. Ноновые сотрудники всегда должны изучить документацию «confluence», в котором всё должно быть подробно описано в плане логики и технологий. Но хрен. Confluence был составлен достаточно поверхностно, просто описание экрана и что он делает. без какой-либо логики. Чтож..... И не такое гавнецо мы видели, засучили рукава и давай кидать лопатой. Об этом пониже.

Tempo — с этим сталкивались все разработчики и менеджеры. Функционал Jira трекающий время сотрудников по таскам. Вроде бы полезная штука для управления персоналом, особенно если их ЗП зависит от отработанного времени. Я не против. Правда мобильная команда работала немного по другому графику и договоренностям. Вот отрывочек (скрины класть не буду).

А. [20.04.17 00:16]
и это, уточнить, мобильщики работают по времени или по фиксу?
П. [20.04.17 00:17]
фикс но праздники двойной счетчик
А. [20.04.17 00:17]
гуд, а то я чисто и тайно попрошу своих в выхи еще попилить
П. [20.04.17 00:17]
оке
П. [20.04.17 00:17]
считай главное правильно
А. [20.04.17 00:18]
ты про приоритеты? :)
П. [20.04.17 00:18]
и время

Ну вы поняли. Полночь, Телеграм, я и ребята еще работаем, параллельно обсуждаем с П. задачи и условия труда. Кстати это всё случилось за пару часов до момент Х, о котором я напишу ниже. Но самое милое, что П. переживал за время... Тоесть вот те 100+ тасков мы должны были сделать за 20 рабочих дней, потому что ребята из фонда «брилиантывентурес» (пускай так) ждут релиза уже с сентября 2016 года. Т. е. я то понимаю про приоритеты и сроки, а вот П. вероятно доверившись «опыту» Б. (с которым он много лет работает вместе) не понимал на тот момент масштабы просраного времени. Хотя Tempo Б. всегда был в порядке. Всегда 8 часов в день.

Еще хотелось бы сразу заметить про весь пакет Jira + Tempo. Б. забрал у всех коллег (руководителей) права администрирования и постоянно мониторил ленту происходящего. Вероятно золотая жидкость будущей прибыли перекрыла всю логику и погрузи его в море амбиций.

Простите, чутка отвлёкся. Последнее в этом пункте — google calendar. Сразу скажу не видел, не знаю, никогда им не пользовался и ссылок не получал.

Документация
Оу, тут интересней :) Я об этом даже чутка выше упоминал. Ведь ребята кто только начал заниматься проектом, должны понимать как этот самый проект работает и какая у него логика.

Confluence — я видел настоящий конфлюенс от настоящего системного аналитика и даже я не технарь (в частности) мог понять там абсолютно всё! В конфлюенс проекта Ф. было всё описано поверхностно без каких либо данных. Увы, но менеджер Б. очень гордился тем что это вообще есть в проекте. Поэтому мы вообще не пользовались этим пунктом в работе. Расхождения между написанным там и реальностью достигали 99,9%.

Swagger — к нему мы получили тоже доступ, через недельки 2, когда уже в десятый раз попросили ребят нам предоставить доступ. Не осуждаю ребят, благодаря политики управления проектами П., любая задача становилась критической и ребятам просто не когда было собирать инфу для передачи.

Postman — штука хорошая, но увы нам так и не получилось с ней поработать, возможно с ней даже и не работают на проекте вовсе, но написать её нам, наверняка требовалось. Стартап же IT и не а бы кабы, а международный!!!

Дизайн
Ох, любовь нынче всех дизайнеров — это скетч. Там можно почти всё, раз ве только не делать сайты и приложения из макета. Помню как я до середины 2015 от него отнекивался, но занимаясь Aviakassa пришлось сесть и научиться в нём работать. В результате я подсел.А что же не так со скетч в Ф.? Да всё нормально, кроме того, что все макеты разбросаны в разных папках, их актуальность не понятна и найти что-то быстро уж никак не получится. Для всего этого был придуман отличный софт под название Zeplin который помогает разработчику без владения Sketch (100 баксов стоит версия) изучать макеты, вытягивать оттуда готовые ассеты иконок и просто сверяться с тем что он делает с помощью функции сравнения. Поэтому у разработчиков часто не находилось возможности открывать макеты дизайнера, его версия скетча была старше чем версия стоявшая на компах ребят и разумеется всё было лицензионное (зачеркнуто).

Аналитика и мониторинг

Тут можно много рассказать для чего создана амплитуда и сентри, но думаю те, кто занимается разработкой давно уже перестали холиварить на тему «микспэнел или амплитуда или апсфлайер» и так далее. Поэтому данный пункт я пропущу почти весь.
Единственное что хочу уточнить, что Б. вероятно не знал о аналитике приложений вообще ничего и не думал что в проекте подключён Fabric (там же где и crashlytics), вот только аналитика никогда не была активирована, поэтому использовать 100% удачный продукт на 5% во время разработки и перед релизом используя TestFlight — это прям верх «профессионализма».

Разработка
Тут становится еще раз понятным почему я готов осуждать Б. в его работе (а он руководил мобилкой 6+ месяцев) и говорит что всё сделано через жопу, так как для него это были основы основ. Он забыл упомянуть например SourceTree, Xcode, Fabric тогда уж, раз в разработке есть Сrashlytics. Ну да ладно, чего уж там. Приведу цитату П. про всё это:
Не иди на конфликт с Б. плз, я с ним работаю 9 лет и он делает все возможное, из за не хватка времени и ресурсов что то могло идти не так.
О да, он делал всё возможное, чтобы за 6+ месяцев проект так и не был сделан. Точнее как, он то «работал» усердно, вот все остальные работали не так продуктивно.

Ну а теперь самое интересное, что я увидел работая в стартапе Ф. и чем занималась мобильная команда.
Хотелось бы описать всё одной гифкой, но ведь не зря я написал всё выше, значит гифки не будет.

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

Тоесть вот те 100+ тасков мы должны были сделать за 20 рабочих дней, потому что ребята из фонда «брилиантывентурес» (пускай так) ждут релиза уже с сентября 2016 года. Т. е. я то понимаю про приоритеты и сроки, а вот П. вероятно доверившись «опыту» Б. (с которым он много лет работает вместе) не понимал на тот момент масштабы просраного времени.

За 1-2 дня все таски были перебраны и обсуждены с коллегами из направлений avia/hotels/cars/profile и тщательно дописаны. Увы культуры написания таска Б. так и не смог не ввел в команде и почти 80% было написано по простой схеме — Название таска должно дать понять что там вообще происходит, что поломалось, что надо сделать, что поменять.... Тоесть нифига не понятно. Ну ладно, мы с этим разобрались. Теперь вроде стало понятно что и как да почему.

Всё отлично, план обсуждённый с П. по релизу преложения к концу месяца вроде бы и не такой пичальный, так как ребята молодцы и я не побоюсь этого слова «ебашили» как проклятые со второго дня работы, без изучения документации. Я увы успел написать только два мини-отчета по разработке и вот как они выглядели:

Общее количество задач мобильной команды 111 (+38 к началу месяца)
Отчёт за период 03.04. — 09.04
Задачи в статусе «done» 23 (17 баги / 6 остальные)
Отчёт за период 10.04. — 16.04
Задачи в статусе «done» 40 (17 баги / 23 остальные)

Задачи в статусе «in progress» 10

Задачи в статусе «in review» 2
Задачи в статусе «todo» 7

Это отчёт по каждой неделе в отдельности. В общем-то в день моего ухода ситуация была такова, что уже был сделан релиз в app store (по желанию П.), версия сборки в нём была не самая актуальная и с багами, так как всё это было 18 апреля, П. был предупреждён о всех последствиях. Хозяин, Барин. Вот собственно тот самый релиз в Jira под версией 1.0.3 ( на самом деле в app store он был 1.0.4) + я приложу еще два скриншота с релизами из того же Jira, которые мы уверенно были готовы закрыть к официальному релизу. Никому бы не было стыдно ни за что. Нигде бы ничего не падало и зависало. Но увы, планам не суждено было сбыться.

1.0.3 — то что команда сделала за 13 рабочих дней

1.0.4 — что оставалось сделать еще за 7 рабочих дней

1.0.5 — что оставалось сделать за 5 дней в релизном приложении

Я думаю не стоит говорить о том, что команда потрудилась отлично и сделала то, что можно было бы сделать раньше, за те 6 месяцев работы. Оценке ребят и моя личная, почему я считаю что 6 месяцев до апреля приложение делалось через жопу ни как не связана с поведением П. (попозже, терпения чутка) и Б., а чисто на опыте. Например:
Форма поиска авиа работала отлично, крутая анимация, возможность выбрать кол-во пассажиров. Но. Я мог выбрать по всем типам пассажиров 999+. Те кто в теме поймут что в любом сервисе есть ограничения по типу пассажиров. И эта логика должна быть заложена изначально, иначе каждый поиск приводит к ошибке, а запросы таки отправляются. Т. е. Мы на третьей неделе своей работы впилили логику основываясь на своём опыте и опыте работы с GDS/OTA/Метами. Вот так например логику формы мне описал продакт О., когда я попросил как положено, в Jira, в нужном таске её написать:

Общее количество взрослых не может быть более 9 если не выбрано ни одного младенца или ребёнка. Выбрать ребенка или младенца без взрослого нельзя. На одного взрослого выбирается не более 3 детей включая инфантов.

Прикольно. Не знаю чем занимался продакт авиа всё это время, если его устраивала работа по принципу «999+», но в результате с помощью коллеги и меня, мы подсказали ему как это написать грамотно. Он просто взял и скопировал в таск:

ADT 9
CHD 8 + 1 ADT
S INF 1 + 1 ADT (max 5ADT +4INF)
L INF 1 + 1 ADT (max 5ADT +4INF)

SEN 9

По факту, когда таск переводился мной на разработчика, он был дописан вменяемо и передан в работу:

Adult — максимально 9 (без детей, инфантов и синьоров)

Children — может быть до 8 детей и 1 взрослый (обязательный)
Seat infants — 1 штука + 1 adult (маскимально 5 adult + 4 infants)
Lap infants — 1 штука + 1 adult (максимально 5 adult + 4 infants)
Seniors — максимально 9 (без детей, инфантов и adult)

В направлении avia было еще много недоработок и багов. Точно так же обстоят дела и с cars у Б. где очень много функционала не было реализовано, а логики уж тем более. Вот простые примеры из рабочих процессов.

— Привет Б. слушай, там в таске написано в фильтрах 06 from 65, а ребята из USA говорят что надо писать 06 of 65.
— Мне кажется ребята правы, ведь мы говорим о количестве доступных предложений из общего.
На что Б. отвечает приблизительно «А, да? Ну давайте переделаем».

Правда вот когда писался таск, ему задавался этот вопрос и он на него так и не ответил ни разу.
Или вот другой пример.

— Привет Б., тут ребята пилят таск по оборудованию для проката авто, там на серваке это еще не реализовано, чтобы на окне подтверждения пересчитывались цены, но мы всё передаем, списывается уже цена с добавленным оборудованием. Если к релизу не будет готово, мы этот комит откатим.
— Ну вы это, не выпиливайте таск!!! Вы чего!!! Мы что-то придумаем по быстрому, если не успеем, ну что ж поделать, главное не откатывайте!

Понятно, же! Этот экран был уже давно сделан, но не работал. Осталась неделя до релиза и мы за него наконец-то взялись. Всё сделали и нам говорят «молодцы, но у нас не готово, но это надо». Круто. И то что пользователь навыбирает оборудования на 300 баксов (например), а на экране оплаты их не будет, зато спишется — это ок. :) Кстати проект cars был первым проектом и собирался на obj, потом к нему присоединились hotels и avia, но форы не получилось, нифига на cars сделано не было.

Вспомнил еще явный пример крутого менеджмента и любви к продукту. Значит есть слайдер на выборе времени аренды автомобиля. Его логина достаточна проста — никакой логики. Я могу двигать слайдеры как угодно и они живут своей жизнью. Я могу выбрать аренду авто на 1 день, тоесть взять и сдать в тот же день и форма мне позволит сделать это очень «красиво». Либо я могу взять и сдать машину в одно и тоже время, либо я могу взять машину например в 10 утра, а сдать её в 7 утра того же дня в том же месте... Слава логике! Слава менеджменту.

И пока писал всё что ниже, вспомнил еще один пример (простите).

— Слушай Б. нам нужны маски номеров для тех 10 стран в офф. релиз. У нас же sms уходит автоматически после ввода номера. Где посмотреть? Есть в документации?
— Ээээээээ, у всех стандартно 10 цифр. Никаких масок нет.
— Ты уверен? Вот в Австралии и Японии не 10 цифр в номере
— А, да? Ого! Значит надо поискать готовое решение, кто-то же до нас сделал!

Т. е. парень всегда думал что во всём мире 10-ти значные номера... И да, изначально форма авторизации была запилена только под RU и US. Крутое решение! И возможность авторизации на 10 стран надо было срочно пилить за 4 дня до релиза.

Самыми беспроблемными были сервисы — hotels и profile. Там у ребят всё нормально с логикой, готовностью к релизу и так далее. Были правда проблемы с привязанными картами, но там такая адовая логика, что её поймёт только сам П.
Но вообще опять таки по нашей «независимой» оценке (моей и ребят) приложение состоит на 70%+ из костыльных решений и непонятной логике. Так же собиралось и всё остальное. Например было вот так (из мелочей).

Если в cars на экране добавления водителя установить ограничения (а их там никогда не было и дату рождения можно было указать аж в 2999 году или как-то так) на барабане (он же UIDatePicker), например чтобы дата всегда ставилась -18 лет от текущего дня, то всё это хозяйство ограничений прокидывается на hotels и avia.

С логикой в сервисе достаточно большие проблемы, она скорее всего основана на интуиции основателя Ф. и является приоритетной, даже если прямо рассказать почему логика не понятна или не правильна для пользователя — это не возимеет никаких действий со стороны П. Надо делать как он сказал.

Так например возникло желание сделать онбординг для приложения и переделать логику главного экрана за 6 дней до дедлайна. Эти желания П. что-то изменить кардинально до релиза мной максимально возможно пресекалось ибо в таком случае мы бы никогда не смогли выпустить релиз, да и ребята из фонда «брилиантывентурес» уже ждали достаточно долго релиза с сентября прошлого года. Нельзя было подводить, ведь в разговоре с ними, я полностью рассказал что мы делаем, что сделали, когда сделаем и чётко описал сроки релиза до 1-го мая. Они были очень довольны и улыбались, так как видимо впервые за долгое время они увидели что-то рабочее в TestFlight и это рабочее говорило о том, что проект действительно делают и делают быстро не в ущерб качеству.

Кстати уже не секрет и ничего секретного нет, так как apple и сервисы хранят данные о приложении, по желанию П. «секретный» релиз был опубликован 18 числа.

1.0.4 ⇡ 21.04.2017
1.0.3 ⇡ 20.04.2017
1.0.2 ⇡ 18.04.2017

Релизы эти начались потому что П. выразил желание давать возможность друзьям/коллегам/инвесторам видеть релиз в app store и не использовать TestFlight. П. был полностью предупреждён о всех последствиях данного релиза, о том, что мы его делаем и забываем, так как на носу через 10 календарных дней дедлайн. Было получено ОК, Я ВСЁ ПОНЯЛ. Ну ок, мы это сделаем. Чтобы вы не думали что П. такой уж вот злодей, а я просто наговариваю на него. Расскажу о своих косяках во время работы.

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

П. [07.04.17 17:46]
в машинах ввел nice — ничего не выбираю и оно выбирается само через пару секунд
А. [07.04.17 17:46]
1й раз была ошибка с моей стороны что и внешним пульнул, понимаю, осознаю, не повторю
А. [07.04.17 17:49]
Тестирование в тестфлайт = путь к стабильному продукту. На то он и тестфлайт.
А. [07.04.17 17:49]
Но теперь буду аккуратней с внешними и внутренними тестировщиками

Это был единственный пр**б за время работы над продуктом.
И вот мы подходим к дню Х.
Там выше я писал диалог с П. в ночи. Приложение уже было в store (секретно) и был 1 апдейт, так как П. посчитал что в сторе очень критический баг и его надо устранить иначе как же «секретный» релиз будет существовать, а люди покупать. И вот наступает 2 часа ночи 21 апреля. В чатик «для неформальной беседы» (telegram) залетает П. и начинает рассказывать кейс в котором пользователь не смог купить отель, потому что приложение выдало ошибку перед оплатой.

Мы сразу все в ночи начинаем выяснять почему же так. Как оказалось, старый разработчик iOs не закомитил своё изменение, а о такой ошибки мы не знали до сего момента. Он знал. И приложение в app store! О боги! Тот самый «секретный» релиз о котором мы должны были забыть установило себе 2 друга П. и один из них попал на такой вот баг.

Нам было предложено к утру купить отель этому другу за $700+. Круто да. За свой счет. Я конечно же начал возражать что никто не виноват, и что тестовая сборка как и «секретная» еще имеют ошибки с которыми мы работаем. Как вы думаете, что я услышал в общем чате? :) Услышал я следующее:

П. [21.04.17 01:02]
так что внутри разрулите сами отель обеспечьте
П. [21.04.17 01:02]
в жопу тестфлайт
П. [21.04.17 01:02]
это блять не игры
А. [21.04.17 01:02]
круто
П. [21.04.17 01:02]
это реальные покупки
П. [21.04.17 01:02]
где люди выбирают то что им надо
П. [21.04.17 01:02]
а не в игрушки играть

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

Финал (5)

В эту ночь я смог уснуть выкурив с десяток сигарет, попытавшись переварить всё что произошло и понять в какой момент П. решил переложить ответственность за принятые решения на других. Я понял что это происходит уже не первый раз и ребята почему-то компенсировали такие вот кейсы из своего кармана. Я чётко сказал себе «я не терпила и такой ошибки могло бы не быть если-бы кто-то занимался приложением как положено!». Да, часть вины я всё таки вменяю Б. за то, что после его управления нам досталось в прямом смысле этого слова сырое приложение и срок в 1 месяц. Мы не просили космических гонораров, мы не кричали что мы супер крутые. Мы просто делали качественный продукт. Хотя за переработки нам не платили.

Понимаю что часть вины и на мне, ведь в компании нет тестировщиков и все баги/таски полностью проверяются самими разработчиками и мной. Вот например С. (тот самый тестировщик) увидев приложение за 5 минут нашёл около 20+ багов и не стыковок в логике... Он делал обычные для пользователя действия и нашёл всё это. Я конечно же попытался «отмазаться» и сказать что мы всё исправим, на самом деле исправили почти всё, но было конечно-же горестно признавать что настолько сырой продукт мы взяли в работу.

Понимаю что часть вины на мне, так как я не тестировал покупки и прочее, но увы. Вы бы согласились оплачивать отели/машины и перелёты за свой счёт и потом возвращать деньги по непонятной схеме? Я нет, уже был опыт и больше я так делать не буду.

Понимаю что возможно был груб и дерзок, но в тот момент меня переполняло чувство недоумения в перемешку с ненавистью к П. и Б. за то, что свои проступки и недоработки они хотят скинуть на меня и команду, которая вытащила из говна их продукт за 3 недели.

Я понимаю. Не одобряю. Признаю. Но считаю что поступил правильно.
Утром 21го числа я и ребята написали письмо где уведомили всех об уходе из проекта. Я увы «соскочил» побыстрому в тот же день, а ребята остались отрабатывать 15 дней по контракту. П. официально подтвердил что с 21 апреля 2017 года я перестаю работать по контракту в Ф. Резонно я сразу дала вопрос «а как же оплата»? и получил ответ «не позже конца месяца».

Как адекватный человек, я сообщил что «принято» и начал ждать занимаясь своими делами, когда заветная и не столь крупная сумма упадёт на мой банковский счёт. От коллег я слышал что П. распорядился расчитать меня и выплатить деньги. Ну круто! Ждём.

После финала (6)

Шло время. Принцесса подрастала... Ой, тут у нас же не сказка, а хорор. В общем я смиренно дождался 00:00 1 мая (время московское) и проверив свой баланс не ощутил никаких финансовых поступлений. Сразу же отправил письмо вот такого содержания:

Приветствую.
Как было обещано ранее «не позже конца месяца», не поступило. Сегодня 1 мая, на баланс на счету не изменился. Оплата за 14 рабочих дней не поступила.
Как я понимаю, та же ситуация у С. и Ал.

Вероятно П. был сильно занят и смог ответить только в начале третьего ночи. Причём все коллеги из USA которые отвечают за финансы кротко молчали. Вот такой диалог получился в письмах. Пунктуацию и бла бла бла я не изменял.

**- да ты маньяк информационный как погляжу ;) лумал, как де ты умудряешься в день десятки комментов и постов делать ;) тебя ждет «великое» будущее. термин расчет и часовые пояса приведи в порядок, а так все по договору.
а по ребятам не беспокойся.
думаю предложить им зарплату больше чем ты можешь найти на рынке торгуя ихними знаниями, и идей больше. если откажутся — будут как ты по жизни маяться и менять проекты по три за год и нигде не получая респекта, что жаль, потому как могли бы.
всем писс и спасибо!**
— Когда ждать обещанной оплаты?
— все по договору

В общем-то я сделал свой вывод. Тот человек который так радовался и радостно принимал всё по работе от меня и команды, в мгновение ока превратился в полное гавно, только потому что за его ошибку не захотел заплатить другой. Тоже самое произошло и с Б. На все мои вопросы «почему слайдеры работают без логики» он отвечал мне ссылкой на описание их работы и не давал ответа «почему это не сделали сразу или за эти 6 месяцев».
Тоесть ни П. ни Б. не могут признать свои ошибки и как-то их обсудить. Виноваты все кроме ...

Еще я вспоминаю как на встрече П. сказал что частью своей доли он поделился с командой (не в РФ, а та что в штатах) потому что так требуют законы и инвесторы. Но спустя неделю, он прилюдно сказал что никого не устраиваем в компанию, в ней никто не работает, все будут «независимыми» наёмниками не имеющими права ни на что. Так проще компании с налогами и проще расставаться, ведь в одностороннем порядке только компания может уволить ежесекундно своего сотрудника, а ежели сотрудник решит уйти от компании, то только 15 дней отработки с письменным заявлением.

Вывод и немного о себе (7)

Лично я считаю что я виноват больше всего в том, что на руках у меня нет подписанного двумя сторонами контракта. Я виноват что привёл своих ребят, своих друзей в проект где они столкнулись с кучей неадекватности. Я виноват что написал всё это и высказал свою точку зрения, ведь у П. есть своя и он мне её высказал.

Я виноват что всё еще верю в порядочность людей и бизнесменов. Допускаю то, что они не могут поступить так или иначе, потому что я бы так не поступил. Я верю людям и буду верить. Но каждый раз я буду набираться опыта и вера моя будет всё яснее и яснее. Когда-то к годам 40 я перестану слепо верить.

Деньги мы в итоге получили. Ребята ушли из компании. Да и много кто ушел из компании спустя какое-то время.

Я не преследую цели посрамить проект или его руководство с менеджментом. Просто считаю нужным донести до многих простую истин. Продукт — это не директор, а вся команда и если вся команда страдает от директора или его менеджмента, следовательно то же будет и с продуктом.

PS. спасибо что прочли всё это, несмотря на очепятки и грубое форматирование текста.

Поделиться
Отправить
Ваш комментарий
адрес не будет опубликован

ХТМЛ не работает

Ctrl + Enter
Популярное