Олександр Димо , 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 - це найкраще, що ми можемо Зробити, і робимо, продовжуємо розвивати далі. І, на відміну від Твіттера, ми не хочемо переписувати Acunote на іншу мову, тому що проблеми з продуктивністю, в общем-то, вирішили.

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

Але Ruby теж розвивається. Версію 1.9, починаючи з 1.9.3 цілком можна використовувати, якщо починати новий проект саме на Ruby, то варто брати саме її. У цій версії гарна продуктивність, менше проблем з Garbage Collection, частина старих проблем успішно вирішена. Наприклад те, коли завантажуєш весь свій код в пам'ять, і в тебе вже GC завантажується, тому що занадто багато коду, а він розташовується в тій же області пам'яті, де ти зберігаєш свої дані, і ти в підсумку прибираєш і весь свій код, який не потрібно прибирати і дані, які потрібно. Зараз це усунули.

Можливо, в майбутньому, Rubinius стане реальним вирішенням. Зараз він просто недороблений. Десь року через 2 це буде потенційно можливо.

- А які плани щодо розвитку Acunote?

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

Acunote, наприклад, може сказати, хто з людей найефективніше планує або найбільше планує, скільки завдань переходить з спринту в спринт, відповідати на величезну кількість запитань проджект-менеджменту. За допомогою графіків можна побачити, хто, власне, в команді планує завдання, хто їх виконує і тому подібне. Трапляється, що компанія наймає нового співробітника, за великі гроші, а в результаті виходить, що ефективність всієї команди відразу падає. Ось аналізом подібних ситуацій ми займаємося і плануємо займатися найближчим часом.

- Спасибі!

P.S. Дивіться також перший випуск Профіт Шоу з Глібом Аршиновим .

Опубліковано: 07/12/12 @ 08:03
Розділ Безпека

SEO Блог

Олександр Димо , Acunote : про agile , Y Combinator і мовах програмування

Рекомендуємо: