Pull to refresh

Как получился Indie-Tracker

Reading time4 min
Views795
Я разрабатываю онлайн-сервис таск-трекинга для небольших команд разработчиков. Он будет очень простым и наглядным, с современным графическим интерфейсом. Чтобы начать им пользоваться, достаточно пройти по ссылке внизу поста и зарегистрироваться.
Сейчас я расскажу, почему во время разработки программы я несколько раз изменял её концепцию. Какие ошибки я допустил и к чему пришел в конце.

Зачем?

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

Первый эскиз

Я успел поработать программистом в малых и в средних компаниях, а также фрилансером. В самой крутой команде было шесть программистов, один менеджер и еще один очень главный менеджер, плюс группа девочек-тестеров. Раскидывали задачи с помощью сложной и страшной системы Atlassian Jira: заходишь по ссылке, жмешь кнопочку и получаешь список своих задач. Ничего о ведении проектов я так и не понял.
Но все же у меня возникло представление о системе ведения задач. В качестве пользователей я видел себя и маленькие мифические команды и решил, что распределения задач по исполнителям не нужно.
Первый блин вышел таким: на основном экране программы был свернутый многоуровневый список. Он состоял из категорий, под-категорий и задач. Еще были мульти-задачи — я думал, что это круто. Выглядело это примерно так:

image

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

Плюсом программы была компактность: на небольшом экране можно быстро оценить состояние всего проекта. Но негде было посмотреть список “текущих” задач, то есть программа не отвечала на вопрос “что нужно сделать сегодня?”. Но тем не менее, так я видел продукт. Хорошо, что я не успел его таким доделать.

Развитие интерфейса

Первые причины для пересмотра концепции я нашел сам. Категории казались сложными, громоздкими и ненужными, программа не давала то, что нужно. Как я вообще это придумал? Я снова начал просматривать существующие аналоги. Отказался от мульти-задач и категорий, теперь задачи отображались простым списком. Добавил вверху колонки три кнопки, чтобы можно было прятать задачи определенного статуса, например, завершенные. Еще добавил новые колонки: комментарии к выбранной задаче, релизы — список важных задач, историю изменений.

image

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

Испытание в реальных условиях

Последним местом работы была новая маленькая компания, занимающаяся одним небольшим, но успешным проектом. У нас было два художника, три программиста и дизайнер. Как в любой команде, здесь существовал процесс распределения задач. Но делали они это — смешно сказать — в google-таблицах. Моим трекером еще никто не пользовался, и я предложил компании использовать его для управления. Но он им не подошел, он вообще не соответствовал нуждам команды. Тогда, работая прямо внутри целевой аудитории своего проекта, я стал наблюдать за внутренними процессами, пытаясь понять, что же им было нужно.

Задачи записывались в google-таблице, где на каждого человека была заведена своя колонка. Списки задач обновлялись примерно раз в неделю. Казалось бы, никакого функционала не было, почему они это использовали? А потому, что это было очень просто: кликнул в ячейку — ввел текст задачи. Или выделил и удалил. Никаких popup-окон, кнопок “ok” и т.д., только быстрый ввод и отображение. А самое главное — всего в одной таблице каждый человек мог видеть свою личную колонку, а “начальник” видел колонки всех остальных, и было ясно-понятно, кто что делает на этой неделе.

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

В результате я стал многое переделывать, началась генерация идей. Иногда я что-то рисовал, объяснял и показывал на работе, получал комментарии и двигался дальше. Проект стал развиваться гораздо быстрее, чем раньше. У руководителей больше интереса было в просмотре задач по отдельному пользователю по нескольким проектам, управление итерациями и приоритетами. Другие идеи приходили от личного опыта работы в компании. Они касались удобства работы в трекере именно исполнителя задач. А самый неожиданный опыт пришел из сферы разработки игр, он касался пользовательского интерфейса.

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

image

Вывод

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

Подвал

На данный момент проект находится в стадии развития, бета-версия доступна тут.

Спасибо за внимание.
Tags:
Hubs:
Total votes 36: ↑28 and ↓8+20
Comments31

Articles