Компания «МТС» надрессировала легион девушек-операторов, которые спрашивают «как они могут ко мне обращаться», постоянно «благодарят за длительное ожидание», а потом «желают удачного дня», прощаясь и передавая звонок в другой отдел.

Для восстановления сим-карты с отрицательным балансом необходимо трижды сообщить мой номер телефона, на кого оформлен договор, кодовое слово и прочую лабуду операторам разных отделов. Процесс затягивается минут на 15-20. Я постоянно жду и слышу «ожидайте ответа оператора в течении… четырёх? … минут?». Именно вот с вопросительной интонацией!

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

Я не ощущаю человечности, общаясь с этими людьми.

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

Универсальные операторы, видимо, стоят дороже, но в этой ситуации можно было бы здорово сэкономить на их количестве.

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

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

— один мой начальник

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

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

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

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

А вот формат гитовых сообщений у нас устоялся:

Fix: [Admin] Fixed some steps for viewing timetable scenario, refs #773
New: [agency] add order checks, validations, add person and waypoint walidations, closes #753

Перед сообщением указан тип изменения, например, новый функционал начинается с New. В квадратных скобках указана область приложения, которую затронули изменения, а в конце указан номер задачи в системе redmine. Этот формат довольно просто соблюдать. А если к нему привыкнуть, он позволяет вообще не думать, что надо написать в строке сообщения. К тому же, он приучивает нас не лить в один коммит много изменений. Полезность этого правила больше, чем трудности, которые связаны с его использованием. И поэтому оно у нас «прижилось».

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

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

После того, как скачаете русские словари для кодировки UTF-8 (файлы ru.utf-8.spl и ru.utf-8.sug), положите их в каталог ~/.vim/spell и выполните команду

echo "setlocal spell spelllang=en,ru" >> ~/.vimrc

Английские словари, как правило, в системе уже установлены.

А для проверки пунктуации в русском языке можно быстренько посмотреть сайт Ильи Бирмана.

Как-то раз Макс сказал: «В шесть часов вечера у нескольких миллионов людей по всей России возникает вопрос: „Чем бы заняться?”». У меня же закрадываются подозрения, что этот вопрос возникает у многомиллионного населения страны значительно раньше. Уже где-то после обеда.

И вот оно спасение, казуалки! Сиди, выращивай брюкву или что там можно выращивать в «Весёлом фермере», в котором уже более 8 миллионов аккаунтов.

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

На данном уровне наших знаний и навыков, добавляя новые функции к нашим приложениям, мы пробуем действовать по следующей схеме:

Продумывание функционала → Эскиз интерфейса, последовательность экранов → Описание функционала в интегральных тестах → Написание представлений → Написание модели и контроллера → Доводка дизайна, рюшечки

1. Продумывание функционала

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

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

2. Эскиз интерфейса, последовательность экранов

Когда мы поняли, что пользователь собирается делать с новым функционалом, рисуем последовательность экранов для каждого действия. Например, добавление заказа — это посещение страницы заказов, нажатие кнопки «Добавить заказ», заполнение полей заказа, нажатие кнопки «Создать заказ» и автоматический переход на страницу просмотра заказа для того, чтобы его можно было распечатать.

Я делаю эскиз каждой страницы маркером на листах А4. Качественный, без деталей. На данном этапе мне не важно, каким шрифтом будет набран заголовок страницы и где что будет расположено. Важно понять, что вообще будет на каждой странице.

Схема каждого действия всегда должна быть перед глазами у разработчика. Иногда держать всё это в голове очень непросто.

3. Описание функционала в интегральных тестах

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

4. Написание представлений

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

Когда тесты написаны и падают, я пишу под них сами вьюшки. Тесты не дают забыть что-нибудь отрендерить и не заставляют городить лишнего. В итоге появляется только то, что было задумано на втором этапе. Замечу, что я пока не могу даже посмотреть, как выглядят страницы приложения на экране компьютера — нет ещё ни единого контроллера.

5. Написание модели и контроллера

Макс тоже сперва пишет функциональные тесты. Он также руководствуется нашими рисунками и тем, что он видит в моих вьюшках.

Потом по тестам он, собственно, реализует функционал. Только теперь приложение начинает делать то, что от него хотели. Макс первый видит экраны на своём комьютере. И, как правило, ужасается — дизайн-то боевой.

Потом мы вместе добиваем интегральные тесты и, в принципе, приложение готово.

6. Доводка дизайна, рюшечки

Украшательство! Я придумываю формулировки, верстаю страницы приложения, выбираю шрифты и цвета для элементов. Новый CSS-код появляется в этот момент. Замечу, что новые элементы на страницах не появляется — преображаются старые.

Плюсы и минусы

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

Ещё здорово, что после всего этого приложение работает. Сразу! И если что-нибудь случиться, то мы об этом узнаем.

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

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

Я заказывал визитки. Отправил макет в полиграфию. Там выяснилось, что макет выглядит немного не так, как надо. После того, как я попросил скопировать логотип, мне сказали, что это уже «правка шаблона» и «будет стоить отдельных денег». Я извинился и нашёл другую полиграфию.

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

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

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

У нас несколько иная схема.

Чтобы не пугать самих себя неправдоподобными данными, мы не озвучиваем реальных сроков, поэтому там, где можно было бы сказать (и действительно успеть за) «две недели», мы говорим «месяц». Но всё равно страшно. Потому что другая команда разработчиков назвала бы срок месяца три.

Первые две недели мы собираем информацию, неторопливо раскачиваясь и делая первые прикидки: что да как писать, какие инструменты использовать, кто что будет делать. Короче, пинаем болт. Потому что типа знаем сколько времени реально у нас это займёт.

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

В итоге, мы всё равно продалбываем все сроки, скажем, на пару недель, а иногда и месяцев. Но всё равно делаем это быстрее, чем сделали бы другие с их «ответственным» подходом. И мне нравится такой рабочий ритм.

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

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

Если вы поручаете существенную часть задач вашим подчинённым или работаете в команде, где принято разделять труд, то нередка ситуация, когда то, что должен был сделать другой человек — не сделано.

У нас в команде в таких ситуациях не принято начинать разборки «почему не сделал?». Чаще всего дело не в человеке, а в задаче. Каждый из нас старается не делать лишних вещей и для нас одинаково важно время любого члена команды.

Именно поэтому я стараюсь не просить никого делать то, что не стал бы делать сам.

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

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

Мы никогда не поручаем друг другу бесполезных задач. За необходимость чего-то каждый из нас отвечает в первую очередь своим собственным временем.

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

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

1. Недавно я купил себе новый телефон и наконец-то, по-моему, впервые в жизни, хорошо слышу того, с кем разговариваю. И знаю, что хорошо слышно меня. Эти ощущения позволяют мне спокойно говорить? сосредоточившись на разговоре а не на том, чтобы правильно держать трубку, вслушиваясь в слова.

2. У меня есть друзья, которых можно назвать профессиональными настройщиками Windows. На компьютерах нашей команды стоит операционная система Linux, в которой можно просто взять и начать работать, начать писать код, не задумываясь о настройке. У меня — Kubuntu у Макса, по-моему, Arch Linux.

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

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

5. Переписываемся мы с помощью протокола Jabber и программы Pidgin. Там нет спама и легко можно создавать конференции из трёх и более человек. У нас есть одна постоянная комната, где мы обмениваемся последними новостями и «чувствуем локоть» друг друга.

6. Для удобного ведения блога мы с Женей когда-то написали Симплог.

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

Улучшайте свою среду. Делайте мир вокруг вас более удобным для того, чтобвы вы могли делать то, что хотите! О других действительно мощных инструментах, о которых я сейчас не вспомнил, я расскажу потом. Подпишитесь на наш блог, если хотите быть в курсе.