Правильная организация труда программистов — сооснователь и глава разработки 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.