К концу 2015 года мы запустили опцию переключения между аккаунтами в приложении Basecamp 3 для Android. На первый взгляд, вполне стандартная функция – если вы пользуетесь более чем одним аккаунтом, просто нажимаете на меню и переключаетесь.
Эта опция подошла по всем параметрам, которые мы задаем для новых задач, за которые беремся: ее хотели пользователи, ее хотели мы, и казалось, что ее можно внедрить в рамках двухнедельного бюджета.
Результат: мы внедрили отличную версию переключателя аккаунтов. Успех!
Подпись мелким текстом: У нас это заняло шесть недель. Мы напрочь выбились из бюджета и дедлайна.
Шесть недель на вот эту фигню? Пффф…
Что произошло? Как мы растянули это с двух недель на шесть? И как мы можем называть это успехом?!
Проблема: Мы не владели всей необходимой информацией
Многие программисты получали этот (в основном болезненный) опыт – у тебя оказывается недостаточно информации перед началом проекта. Когда мы изначально планировали две недели, мы думали, что нашего базового кода вполне хватит на разработку данной функции.
Это предположение было неверным.
В ходе разработки и приближения даты запуска все поплыло. Наш код оказался не таким структурированным, каким казался. AsyncTasks (программный класс, который используется для Android-разработки — ред.) сделал код сложным для чтения и еще более сложным для усовершенствования. С нашей базой данных было сложно работать. Каким-то образом там очутились четыре уровня аутентификации. Средства тестирования оказались не такими мощным, как должны были быть.
Но ничего из этого не казалось очевидным в течение первой недели разработки. И даже второй недели. И даже третьей. Ну вы поняли.
Реальное мерило успеха: закладывание фундамента
Сэм Стивенсон, программист Basecamp и один из самых умных людей, которых я когда-либо встречал, прекрасно сказал:
Вместо того, чтобы решать проблему на ходу, одним решением, лучше заложите фундамент для системы, которая будет поддерживать специфические перемены, которые вы захотите в нее вносить.
Собственно, эта фраза объясняет почему наша опция-за-две-недели превратилась в шестинедельный мини-проект. И она же стала абсолютным классификатором успешности данного проекта.
Мы отказались от AsyncTasks и заменили его на Android Priority Job Queue. Мы переписали структуру нашей базы данных. Мы почистили процесс аутентификации. Мы написали новые тесты и улучшили существующие. Мы сделали массу вещей, которые долго перечислять. Мы сделали все, что могли, чтобы улучшить общее состояние системы для будущей работы. (И да, мы написали полностью новый код для переключения между аккаунтами!)
Короче говоря, наша команда в полной мере осознала насколько важно делать вещи правильно, а не быстро. Мы поняли, что переписывание, переработка и реогранизация больших кусков кода стоят наших усилий, поскольку послужат фундаментом на 2016 год.
Да, мы могли внедрить эту функцию за две недели. Но куда важнее было заложить фундамент для нормальной работы и потратить на это шесть недель. Мы следим за дедлайнами, но еще больше мы следим за качеством работы.
Чему мы научились?
Несмотря на то, что мы были рады результатам, остались вещи, которые мы могли сделать лучше. Итак, чему мы научились?
- После первой или второй недели следовало остановиться на пару дней и сделать шаг назад. Это бы позволило нам лучше проанализировать ситуацию, обновить ожидания и задать новый дедлайн. Даже если бы мы пришли к тем же выводам и датам, перезагрузка помогла лучше обдумать существующие приоритеты.
- Когда мы осознали, что все займет больше двух недель, следовало назначить регулярные видео-конференции через Google Hangouts. Обсуждение лицом к лицу (с модерацией) действительно порождает множество хороших идей и решений насущных проблем.
- Следовало делать больше небольших письменных заметок, которые бы помогли лучше описать систему и взаимодействия внутри нее. При обсуждении чего-то комплексного легко упустить суть, общаясь через что-то вроде Campfire. Хорошо, что в Basecamp есть множество опций, вроде списков задач, документов или сообщений, которые позволяют немного замедлить процесс общения – описать проблему более методично и вдумчиво.
- Спешка ведет в никуда. Было пару моментов, когда я думал, что нужно поднажать, нужно спешить, мчаться к финишной черте. Думаю, это вполне естественно, если ты мотивирован и хочешь хорошо выполнить работу. Но мои коллеги помогли мне, и мы сумели переориентироваться на более длительный срок выполнения задачи. Хорошие коллеги всегда помогут принять правильное решение.
В итоге, мы выкатили классную функцию, заложили фундамент на 2016 и многому научились.
Думаю, что такой результат за шесть недель – не так уж и плохо.
