Хорошее ТЗ на вес золота
Нормальное ТЗ - мечта разработчика.
(моё - замазал только чувствительную инфу)
Из жизни отчаявшихся программистов
xxx: я уже согласен на любой разврат, блядство и извращения. Пусть только в техзадании их четко опишут.
Как за 3 недели выполнить “годовой” объем работы
Можно ли год писать 4 экрана для простого iOS приложения? Можно если вы очень ленивы.
Но есть и второй случай: если нет внятного технического задания а делает все человек впервые пишущий код. Тема избитая но на мелких и учебных проектах про это постоянно забывают. И нас это не обошло стороной, а парню пришедшему год назад в нашу контору до сих пор припоминают эти 4 экрана.
Идея:
Как так получилось? У нашего директора каждый месяц вставала проблема: нужно с выгодой для себя перевести валюту в рубли. Казалось бы следишь за курсом в приложениях, на сайтах обменников обмениваешь ничего сложного. Но как бы не было много валютных приложений они все похожи друг на друга и либо имеют слишком скромный функционал либо слишком громоздки и пользоваться ими не комфортно. И к тому же следить надо самому, а человек он занятой, а помнить об этом надо постоянно.
Решение пришло само собой в виде джуна пришедшего разрабатывать под iOS, надо сказать, что несмотря на всю ситуацию получилось в итоге очень годная вещь для решение своей задачи - освободить голову.
Главной идеей была возможность оповещений об изменении курса в необходимых обменниках и максимально простой быстрый и интуитивный интерфейс.
Разработка:
Проблемы начались с того что на старте он не умел ничего от слова совсем. Описанное изначально не очень точно задание, естественно без ТЗ переделывали миллион раз по двум причинам:
1)он не понимает как что либо работает, это не гуглится, а сеньер перегружен и помочь не может. чуть чуть перекроили интерфейс?
Главное что работает и проблему решает.
2)интерфейс кому то не нравится и его снова переделывают
Длилось это перекраивание и допиливание в итоге около 6 месяцев, а интерфейс в результате стал настолько “интуитивным” что люди использующие его впервые гадали по часу, что оно вообще делает, спустя неделю узнавали что тут можно настраивать обменники и виды валют на главном экране.
Несмотря на на все недостатки проблему он решал и был в чем то уникален(мало кто может похвастаться простыми быстрыми в настройке оповещениями). Решено было превратить это в продукт и выложить на appstore и портировать на android.
Началась такая же учебная разработка, в которой участвовали также поголовно джуны, от разраба до тимлида и менеджера.
Тут появилось первое ТЗ. И результат не заставил себя ждать, за 3 недели было сделано то что делалось 6 месяцев, вот она сила чудотворная.
Но не все было просто, приложения должны были быть схожи, по этому все проблемы интерфейса перетекали и туда. Стало понятно что нужен специалист и его нашли. Им стал продукт менеджер. С его помощью удалось получить вполне адекватный макет и.. начать разработку половины экранов заново.
Местами казалось что это проект проклят на незавершенность, одного из разработчиков за пару дней до предполагаемого релиза покусала бешеная белка(да, именно белка) были постоянные проблемы с сервером.
В результате дискоммуникации и неудачного мержа была потеряна еще пара дней, но это даже и близко не стояло по сравнению с тем в каком темпе шла работа в начале.
Со слов разработчика:
“- Проблемы были в том, что я не умел ничего в принципе.
- Нужно было прикрутить проверки подключения к инету, чтобы вывести ошибку, если его нет.
-Я не знал как, и в первых версиях этого не было.
Изначально БД было для того чтобы одна сущность содержала другие, в процессе разработки мы поняли, что нужно, чтобы было наоборот.
-И да, у нас есть массив с массивом с массивом с массивом внутри.
-Апи писали 2 человека, один из которых гендир. Парсеры писали другие люди, в результате сервер отправляет цены в разных форматах. Долго решали, кто должен форматировать, задолбался, сделал на клиенте.
-Свойство, которое определяет есть ли у нас 2 цена дублируется у 3 сущностей, а используется у одной.
-Из за того, что часть функций не реализована, сервак гоняет 30% лишней инфы.
-Апи переписали с нуля за 5 часов, и еще 4 недели фикисли кучу багов.”
Итоги:
Что же получилось?
Получилось, что на, что было потрачена уйма времени и сделано криво, можно было сделать быстро и вполне качественно, в чем на своем примере мы и убедились. Главное было уделить время и разобраться в желаемом результате и донести его до исполнителей. А если этого не сделать, можно и год топтаться на месте.
Насколько хорошо мы справились?
Можете оценить сами, ссылку если интересно будет дам в комментариях.