Сооснователь и глава разработки Acronis Станислав Протасов рассказал о том, как это устроено у них и дал советы начинающим командам
Tproger взял интервью у Станислава Протасова - сооснователя и главы разработки компании Acronis. В первой части читайте о том, чем сейчас занимаются в компании, как в ней организована разработка, какие можно дать советы начинающим командам программистов.
Станислав, расскажите, пожалуйста, над какими проектами вы сейчас работаете?
Над нашими продуктами, над новыми версиями. Что-то улучшаем, каким-то образом пытаемся сделать так, чтобы все наши продукты были связаны, чтобы была единая платформа.
Недавно у вас появился мобильный бэкап, это одна из частей этой платформы?
Да, это просто одна из частей. Мы хотим защищать данные на всех устройствах: мобильных телефонах, рабочих станциях, домашних компьютерах. Сейчас появляется ещё и такая сущность, как Интернет вещей, там возникают дополнительные источники данных. Например, ваш автомобиль с историей поездок, любимыми маршрутами, настройками.
Есть множество данных, которые мы создаем, но не знаем, пригодятся они нам или нет. И если сохранять их дорого или неудобно, то люди этого и не делают. В частности, потому что они безалаберны, ведь это требует какой-то дисциплины. Вот, например, стоит у меня на столе внешний жесткий диск. Если мне надо его включать каждый раз, для того чтобы сделать копию, то меня обычно, несмотря на то, что я относительно дисциплинированный человек, хватает на месяцы. Потом я незаметно перестаю это делать. А если вдруг из него выбило блок питания и надо лезть под стол, я делаю это месяц. Или диск рассыпался, надо заменить - я об этом думаю, потом опять забываю. Но если сделать процесс сохранения очень удобным, подключить облачные хранилища, то я, конечно, буду это делать.
Но тут встает другая проблема - как найти ту информацию, которая вам нужна. Лично я стараюсь все сохранять, не "убиваю", например, свою почту, но, когда мне надо найти какое-нибудь письмо - это просто мука (тут еще есть такой интересный феномен - обычно почему-то находится письмо из прошлого поискового запроса, и я не знаю даже, как это объяснить). У меня есть почта, которую я заархивировал, есть почта, которая живет на моём Exchange, и есть еще какая-то почта на личных аккаунтах. И если я не помню, где ее искать - шансов найти достаточно мало. Вот мы и пытаемся, например, этот процесс сделать удобным - чтобы данные всегда были доступны со всех устройств и их потенциально было легко найти. Над этой системой мы в том числе и работаем.
Как у вас компании непосредственно организована разработка? Как идёт процесс от постановки задачи до выхода продукта на рынок? Какие методологии применяете?
Мы занимаемся своим делом давно и учились во многом на своих ошибках. К примеру, когда я начинал в первой половине 90-х, не было даже литературы по этой теме - программирование, софтверный инжиниринг и т.д. Советский Союз распадался, индустрии коммерческого программного обеспечения в стране не было, поэтому приходилось учиться самому. Это и хорошо, и плохо. Когда человек учится сам, он пробует много правильных и неправильных вещей, начинает понимать, почему что-то работает, а что-то нет - это хорошо. А плохо, потому что это самый долгий путь. Лучше, когда есть возможность учиться у кого-то по уже разработанным программам.
Когда мы начинали, у нас было совершенно детское представление о методологиях разработки. В одной книжке про историю компании Microsoft я прочитал, что, когда они работали с IBM над IBM PC, MS DOS и прочим, у инженеров IBM уже была высокая культура разработки. В частности, потому что в IBM всегда делали железо, а в железе ошибки стоят гораздо дороже. Так вот, инженеры IBM просто впадали в ступор, когда видели идеологию Microsoft на тот момент: "if it compiles… ship it!". То есть в Microsoft не было тогда ни понимания, что нужен quality assurance, ни тестеров - ничего. Скомпилировалось - вот вам ребята! Не работает? Сейчас починим!
"Не очень важно, какой именно процесс разработки у себя в компании использовать, но очень важна итеративность"
Любая компания, которая начинала очень рано, а мы, по меркам нашей страны, начали очень рано, через это проходила. Мы на собственном тяжелом опыте понимали, почему надо тестировать, почему в ночь перед релизом простой fix, который точно ничего не может сломать, обязательно все сломает. Пример: когда мы делали один из наших продуктов, то в ночь перед релизом обнаружили, что в русской версии продукта название программы на экране написано на английском. И инженер, который, кстати, сейчас работает здесь же, в Acronis, сказал мне: "Давай переведем, я соберу, ведь выглядит некрасиво. Что мы можем сломать, мы просто заменим английский текст на русский". Я ему ответил - хорошо. Он перевел - и все перестало работать. А причина была очень простая - русский текст был на несколько байт длиннее и случился "buffer overrun" ("нехватка буфера"). То есть был баг, который не проявлялся в английском варианте, там был фиксированный буфер, туда клалась строчка, а в русском чуть больше - и буфера не хватало. Так что мы все это проходили. Начиная с базовых вещей, что нужно тестирование, нужно фиксить баги, их квалифицировать.
Я помню, как тяжело было понять некоторые методологии в начале-середине 90-х, описывающие интерактивный процесс разработки. Вот есть waterfall, а вот rational unified process, который предполагает несколько итераций waterfall. Сейчас расскажи это любому инженеру - он это поймет, ведь уже и книг написано куча, все работают в компаниях, где итеративный процесс в том или ином виде присутствует. А тогда было непонятно. Потому что в waterfall начинаем мы с требований, потом пишем код, потом мы тестируем, потом выпускаем продукт. Зачем это делать несколько раз, если мы вот тут уже должны выпустить? Extreme programming мы тоже пробовали и использовали, причем во всех его реинкарнациях: парное программирование и т.д. и т.п.
"Когда люди становятся профессионалами, им надо дать возможность самим выбирать инструменты"
По моему личному мнению, с учетом опыта: не очень важно, какой именно процесс разработки у себя в компании использовать, но очень важна итеративность. У любого итеративного процесса разработки, особенно большого и сложного продукта, меньше шансов не завершиться или "уплыть", чем у такого, который предполагает, что сегодня мы проговорили, какой продукт будет, а последующие два года просто не заходим к программистам и ждём. С итеративным процессом разработка становится предсказуемой. А дальше все конкретные методологии дня или года, наиболее популярные - это зачастую вкусовщина.
На самом деле, когда компания строится, когда формируется коллектив, очень полезно иметь один процесс разработки - тогда становится возможным переключать человека из команды в команду. Он просто приходит и знает, что к чему. Знает, к примеру, как и в какую систему репортить баг, если написал код - куда его надо закомитить и так далее. Но когда компания становится большой, профессиональной и начинает делать хорошие продукты, жесткое поддержание единых процессов разработки и строго унифицированных тулсетов начинает приносить больше вреда, чем пользы. Когда люди становятся профессионалами, им надо дать возможность самим выбирать инструменты. Это как с детьми - когда мы хотим развить ребенка и приводим его, скажем, на бокс, то нельзя разрешать детям бить друг друга так, как они хотят. Должен быть тренер, защита, объяснения того, куда бить нельзя и т.д. Но когда человек становится разрядником или мастером спорта, то объяснять ему, какие перчатки использовать или в каких кроссовках ходить, становится глупо и непродуктивно.
Кстати, по поводу начинающих команд. У нас в сообществе довольно много программистов, только встающих на путь становления профессионала. Они объединяются, выбирают проект и начинают его делать. Могли бы вы посоветовать им перенять какие-то аспекты вашей практики организации разработки? Например, стоит ли им использовать Jira, или не стоит, может быть какие-то ещё инструменты.
Очень тяжело давать советы, потому что у разных людей работают разные вещи. Я скажу так: для меня, когда люди начинают ссориться на тему "Jira или не Jira" - это звучит дико. Конечно, лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration. Выбор этих тулзов - вкусовщина. Если люди знакомы с "джирой" - пусть используют "джиру". Если хотят использовать что-то другое и они согласны - ничего такого в этом нет. Но вот непрерывная интеграция (continuous integration) - это важно, " итерационная разработка" (iterative development) - это важно. Кто-то, играющий роль продакт-менеджера, то есть человек, разбирающийся с тем, что же мы делаем, - это тоже очень важно. "Проверка качества" (quality assurance) - это важно. А дать конкретные рекомендации "берите только джиру или не джиру" - это будет глупо, неправильно и не имеет никакого смысла.
"Лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration"
У команд, которые объединяются, на самом деле и так задача очень сложная. Потому что очень часто эти команды - виртуальны, люди которые расположены в разных городах, зачастую даже никогда лично не встречались, и которые хотят сделать проект. В любом софтверном проекте есть шансы на неудачу и в зависимости от разных вводных эти шансы могут увеличиваться. Команда незнакомых друг с другом людей, расположенная в разных городах, сильно увеличивает шансы на неуспех. Не все способны работать удаленно. Я знаю многих людей, которым тяжело работать дома, потому что дома человек пришел, cел за компьютер, хочет поработать, а тут прибежал ребенок, залез на плечи, попросил купить алмазиков в какой-нибудь игре, затем убежал. Человек отвлекся, вдохновение пропало… и он пошел на какой-нибудь сайт. Время ушло. Работать удаленно тяжелее, чем в офисе, для многих людей. В любом случае человеку удобнее, когда его не отвлекают. А дома с этим проблематично.
Кроме того, когда команда распределенная, нет возможности подойти к коллеге и что-то спросить. Вот ушёл человек, который сидит дома, от компьютера, я ему написал в Skype, и он не ответил, а когда он ответил мне - я пошел ужинать. Коммуникация затрудняется.
Нет никакой волшебной книги, которая бы объяснила, как виртуальной команде собраться в вашем сообществе и стать успешными. Люди должны понимать, что, во-первых, такого рода проекты тяжелее делать, поэтому если у них получается - надо тренироваться дальше, это очень хорошее и важное умение. А, во-вторых, нужно всегда держать в голове простую вещь: что, чем бы мы не занимались - время идет, поэтому, если мы хотим делать какой-то один проект, распределенный или не распределенный, нужно стараться себя заставлять этим заниматься с полной отдачей. Потому что время все равно уходит.
Беседовал Алексей Михайлишин, основатель проекта tproger.