×Закрыть

Александр Дымо, Acunote: об agile, Y Combinator и языках программирования

Весьма популярный agile-планировщик Acunote был создан нашими соотечественниками — Глебом Аршиновым и Александром Дымо. Проект вышел «из-под крыла» небезызвестного Y Combinator и продолжает развиваться, несмотря на то, что его основатели в настоящий момент работают по разные стороны океана. К сожалению, командировка Глеба в Киев сорвалась, поэтому пообщаться лично удалось только с Сашей.




— Расскажи немного о проекте...

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

— Как родилась идея проекта? Какова его история воплощения её в жизнь?

Началось это все с того, что Глеб в своей работе должен был руководить небольшой командой людей. Для решения своих задач он использовал Excel в котором и рисовал похожие графики. Понятное дело, что делать подобные вещи можно и в Excel, есть даже специальные spreadsheets для этого, но всё же это не совсем удобно. Более того, эти spreadsheets может вести только один человек — это и стало ключевым ограничением. Даже если сейчас выложить файл в Google docs, то люди станут модифицировать документ как им удобно и никакого порядка не будет.

Собственно, с того, что Глебу нужно было управлять задачами в Excel и начался Acunote. Была идея взять то, что он уже делал и просто реализовать в виде web-приложения. Это было в 2006 году, Глеб как раз ушёл из компании, в которой работал и задумал решить свою насущную проблему.

Это, как по мне и есть самая лучшая задумка для стартапа — решать задачу, которая является для тебя актуальной.

В апреле он нашёл меня по запросу «Smalltalk Киев», как-то так, просто решил в гугле ввести самый странный язык программирования и поискать, какие люди этим занимаются. Я непосредственно со Smalltalk никогда не имел дела, но делал конференцию, один из участников которой им занимался. В мае-июне была создана компания и официально я стал первым разработчиком, сотрудником компании. С 2006 по 2008 год мы начали нанимать людей в Киеве и в Украине, собственно этим и занимаемся до сих пор...

— Большая ли команда?

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

— В итоге Smalltalk к этому какое-то отношение имел?

Нет, мы всё сразу стали делать на Ruby и на Rails, в 2006 году вышла первая версия, это на то время была супермодная технология, и мы сразу стали ее использовать. Как показала практика — выбор оказался хорошим. У него есть свои недостатки, но тем не менее. И в то время нам было очень интересно и намного проще нанимать людей, чем сейчас — они хотели попробовать новую технологию.

— А на Y Combinator как вы выходили?

К ним мы подошли очень интересным образом: наша компания была построена на деньги, что называется у американцев family&friends. Это дало нам начальный капитал, на который мы построили продукт и начали зарабатывать и смотреть, куда же дальше двигаться. То есть, о существовании Y Combinator мы знали, но никогда не думали туда обращаться, потому что мы не считали его местом для компаний, у которых уже есть свой продукт. Мы его воспринимали больше как стартап-инкубатор.

В реальности получилось иначе. У нас было недопонимание того, чем на самом деле является Y Combinator. В 2011 году нам предложили — а почему бы вам не подать заявку как успешному стартапу, который делает неплохой продукт. Ну мы с Глебом и подумали — почему бы и нет? И начали узнавать — что же нам это даст. Оказалось — это не совсем классический стартап-инкубатор, который берёт людей ниоткуда и делает из них компании. В нём какая-то доля участников уже имеет компанию, уже делают какой-то продукт и они хотят его, например, продвигать.

Y Combinator даёт три основные вещи: бренд (потому что Y Combinator-компания — это круто), совет (сам Пол Грэм за 15 минут общения с тобой может понять весь твой бизнес и рассказать тебе, что же делать дальше) и самое главное — сеть компаний, social network закрытого типа, YC Alumni — люди, которые были когда-то в YC, которые сейчас в YC и которые будут в YC.

Это было особенно важно и полезно для нас.

— В качестве менторов или для поиска клиентов?

И так, и так, и в качестве партнеров тоже. Всегда хорошо делать бизнес с тем человеком, которого ты знаешь. Тем более, что ты знакомишься с людьми не только из своей группы, но и с предыдущими фаундерами и с теми, кто поступает после тебя, и это хорошо работает. Например, мы используем Mailgun — ещё одну YC-компанию, которая занимается рассылкой и приёмом почты таким образом, что те письма, которые ты отсылаешь, гарантированно не пойдут в спам. У нас отлично получилось вести бизнес с ними.

И понятное дело, когда работаешь с YC-компанией, она готова для тебя что-то сделать, также как ты готов для нее что-то сделать. Мы делали очень много для тех компаний, которые переходили с других систем на Acunote — для тех, кто переходил с Pivotal Tracker или других систем, мы делали импорт, мы делали больше чем для любых других клиентов.

— А что касается agile—экспертизы — вы привлекали каких-либо «гуру» или весь бизнес-процесс делали своими силами?

Мы сами гуру! Единственное, что — книжку пока не написали. Давно думали над этим, но пока не сложилось. Когда в кармане будет несколько миллионов, напишем...
Те люди, которые считают себя гуру, зарабатывают на консалтинге, мы же — на продукте, так что не можем отвлекаться. Тем не менее, у нас есть свое видение того, каким образом нужно строить agile в компании и agile-процессы. Мы приближаем наш продукт к реальности.

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

— Когда вы с Глебом познакомились, он уже был за рубежом?

Да, он эмигрировал еще в 1990-х годах...

— А у тебя мысли такой не появлялось?

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

— И как с твоей точки зрения удобство распределённой работы?...

Ну, я сам начинал с того, что сам делал какие-то продукты и продавал их. Понятное дело, у меня не было ни офиса, ничего. Мой дом был моим офисом. После этого я начал заниматься open-source разработкой, KDE, KDevelop и другими проектами (и до сих пор немного этим занимаюсь).

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

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

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

— Команда вся украинская?

Да, это люди из Киева, Николаева. Раньше были также Симферополь и Днепропетровск. Но основной рынок труда все равно в Киеве. Мы даже когда-то думали набирать людей из России, но не получилось и потом перестали.

— Как ты пришёл к Ruby?

— У меня с любым языком программирования есть love and hate relationship, в том числе до Ruby я программировал на C++ много лет и не это нравилось, в отличие от многих людей. K Ruby я пришёл, потому что я начал пробовать что-то новое, я всегда любил пробовать новые языки, чтобы оставаться в курсе всего, что происходит.

Сначала объектом экспериментов стал популярный в то время Python (в 2003-2004 Ruby и Python как раз набирали популярность), я попробовал, но не пошло. Наверное, по «религиозным соображениям», не совпали с моими идеи Гвидо ван Россума. Потом я попробовал Ruby и оказалось, что соображения Юкихиро Мацумото совпали с моими во многом вплоть до простых вещей вроде синтаксиса. Это почти как в Паскале — детство вспомнил.

В общем, Ruby подошёл по идеологическим причинам, по экспрессивности, по тому, что я пытался решать какие-то реальные задачи на нем, и оказалось, что дело идёт и идёт довольно быстро.

В отличие от С++, который требует серьёзной работы над инфраструктурой перед тем, как ты начнёшь свой проект, а начинать проект на Ruby очень просто: все что тебе нужно — буквально написать пару строчек. Объём кода уменьшается в разы. Самый лучший код — тот, которого не существует.

Если мы можем сделать Acunote, потратив несколько лет и написав всего несколько десятков тысяч строк кода, это очень хорошо. На С++ мы бы этого не смогли бы сделать вообще.

Естественно, каждому инструменту — своё применение. Модуль ядра на Ruby писать, наверное, можно, но не нужно.

— А как ты к функциональным языкам программирования относишься?

Скажем так: Lisp я пробовал, чуть-чуть пользовал. Идея функционального программирования мне понятна и близка по духу, но реально работать на нем не хотелось бы.

Haskell пробовал, но понял, что чтобы написать те 2 строчки кода, которые решают мою задачу, мне нужно провести 2 дня и потом я не смогу их прочитать. Я решил, что оно того не стоит.
Из современных функциональных языков мне очень нравится Clojure это такая стилизация Лиспа на Java-виртуальной машине очень хорошо. Она менее «религиозна», её создатель, Рич Хики, очень прагматичный человек и у него получился очень прагматичный язык программирования и его очень хорошо использовать.

Scala мне тоже нравится. Ничего реально не решал на этих двух языках, но всё мне нравится.

Если меня сейчас спросить — на каком языке ты хочешь начать свой следующий проект, это не будет однозначный ответ — на Ruby. Вполне возможно Scala или Clojure, несмотря на то, что это не динамические языки.

— И какие планируешь следующие проекты?

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

Большинство проблем вполне решаемы. Есть какие-то принципиальные моменты-ограничения, как, например, скорость современных интерпретаторов но тут ничего не сделаешь...

Но Ruby тоже развивается. Версию 1.9, начиная с 1.9.3 вполне можно использовать, если начинать новый проект именно на Ruby, то стоит брать именно её. У этой версии хорошая производительность, меньше проблем с Garbage Collection, часть старых проблем успешно решена. К примеру то, когда загружаешь весь свой код в память, и у тебя уже GC загружается, потому что слишком много кода, а он располагается в той же области памяти, где ты хранишь свои данные, и ты в итоге убираешь и весь свой код, который не нужно убирать и данные, которые нужно. Сейчас это устранили.

Возможно, в будущем, Rubinius станет реальным решением. Сейчас он просто недоделан. Где-то года через 2 это будет потенциально возможно.

— А какие планы по развитию Acunote?

У нас один, но грандиозный план: у нас есть все данные, которые мы можем собрать от компаний по управлению проектами. Это был наш фокус с самого начала. Теперь мы будем их анализировать и так далее. На этом этапе мы собираем абсолютно все данные о выполнении процессов, ни один другой продукт не знает о проектах, сколько Acunote. Я это знаю, потому что мы делали импортеры из конкурирующих систем, историю все хранят в виде, непригодном для анализа. А если ты хочешь понимать, каким образом работает твоя компания, эффективно ли ты выполняешь спринты, планируешь их, тебе нужна именно history, причём в определённом виде, доступном для анализа. У нас это есть.

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

— Спасибо!

P.S. Смотрите также первый выпуск Профит Шоу с Глебом Аршиновым.

LinkedIn

3 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

У Александра замечательный был доклад на RubyC www.youtube.com/...h?v=CKK8AQIOCyg

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

Не, так никто не делает. Надо потратить еще один день и написать такие 2 строчки, которые решают задачу и легко читаются через год.

При том что Хаскель хорошо читаемый. Его можно в чем то упрекнуть, но точно не в этом.

Подписаться на комментарии