Как стать героем (Яков Сироткин на ADD-2010)/Стенограмма

Ссылки сюда (1) →

Введение

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

Я десять лет делал http://jug.ru, у меня есть ЖЖ, и я люблю выступать на конференциях.

На минном поле нет героев

Ну теперь, мы поговорим, как мне представляется наша индустрия в целом. Есть много программ, у которых есть очень-очень-очень много разных функций. А потом, когда начинается внедрение, заказчика проводят, как по минному полю — а вдруг, что-нибудь да внедрится? Аналогичная схема с минным полем действует и для многих наших аутсорсеров. Т.е. сначала берется как можно больше клиентов, под этих клиентов набирается как можно больше штат, за этот большой штат капает небольшая денежка, а когда деньги заканчиваются, все программисты увольняются, «подрываются».

Нет смысла без своих мозгов

Знаете, даже если вы разрабатываете под IPhone, теоретически вы сможете стать миллионерами. Но статистически вы оказываетесь глубоко в минусе. Была небольшая обзорная статья, которая была посвящена статистике продаж на AppStore, и так получилось, да, что есть очень успешные программы с большими доходами, но большинство получает совершенно смешные суммы.

И я не претендую, чтобы рассказать вам в своем докладе, как делать успешное программное обеспечение. Почему я не претендую на это? Я глубоко убежден, что нельзя сделать успешный софт, если у вас нет собственных мозгов. А собственный мозг я вам не дам. Это технически невозможно. Но на что я надеюсь? Я надеюсь на то, что я затрону некоторые вопросы, над которыми вам будет полезно подумать. Может это вам понравится.

Как стать героем

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

Шум в зале… «Линус Торвальдс», «Сергей Брин», …

Ну на самом деле, должен вас разочаровать (см. слайд). А учится можно у меня, по тому, на что я сам напоролся. Моя ролевая модель — Дон-Кихот, который упорно пытается донести свет истины до начальства. Ну и для всех остальных.

Пытается рассказывать правильные вещи, делать правильные вещи, ну как-то двигаться в общем, вперед. Бывает очень-очень больно и обидно. Не советую.

Капитан Очевидность несколько полегче. Некоторые думают, что это неинтересно, но практика показывает, что всегда находятся желающие поспорить.

Зачем?

А теперь перейдем к вопросу главному — зачем становится героем? Вот смотрите — зарплаты в России, они небольшие очень. Программисты обычно получает вдвое больше, чем в среднем по стране. Если программист обладает какими-то дополнительными качествами, то он получает еще в двое больше, чем средний программист. А качества могут быть разные — знания Java, умение хорошо вести себя на интервью, хороший английский… буквально за что угодно.

И смотрите, как может получится — вот вы пришли на работу, хотите разрабатывать разумное доброе вечное. А ваш начальник хочет смотреть футбол. Кто победит?

Шум и волнения в зале…

Больной вопрос…

Какие задачи вы поручите Бобруйскому филиалу?

Другой вопрос связан с нашей территориальной распределенностью, удаленностью от многих наших заказчиков. Вот представьте себе, что у вашей компании есть филиал в Бобруйске. Поручите ли вы этому филиалу задачу, за которую вам дадут медаль?

Подумайте сами, зачем вам давать задачу в Бобруйск, если вы ее сделаете сами и вам за нее дадут медаль. Вы ее не отдадите. Кроме одного случая — эту задачу невозможно сделать.

Шум в зале → В бобруйске ее за меньшие деньги сделают!

Бобруйск получит свои меньшие деньги. Медаль он не получит. Медаль это больше, чем маленькие деньги.

Шум в зале → Медаль получим мы! А он — меньшие деньги. А большие деньги получат те, кто поручили Бобруйску.

В общем — Бобруйск медали не получит.

Так вот, извините, когда вы из Сан-Франциско смотрите, то там все равно — Бобруйск или Санкт-Петербург.

Кто будет первым пользователем?

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

Хочу сразу предупредить, эти вопросы нужно задавать очень осторожно, потому что если вы их будете задавать очень часто, вы прослывете уникальными людьми, асоциальными типами.

Кто будет первым пользователем?

Use-case простой: вы делаете прототип для министра. Я вам по секрету скажу — министр, как бы вот он, вот он сидит, а вот (показывает на стол в 5 метрах) компьютер. И министр вот так вот смотрит с трех метров. Ему глубоко все равно, там работающий код, или презентация в пауэрпоинте.

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

Кто виноват?

Другой вопрос — кто виноват? Представьте, что вот вы — делаете систему. И выпустили ничего. Вот год работали, а релиза — нет. Ничего не случилось. Сплошные баги. Кого накажут?

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

Значит накажут испольнителя …

Ну как можно наказать? — можно уволить — ну значит уволят. Еще могут поругать — поругать могут, относитесь к этому спокойно.

Вы понимате, что очень тяжело сделать проект, если в его успехе заинтересованы только вы, но не тот человек, который выделяет на него ресурсы.

Этот вопрос — хороший, потому что если окажется, что кто-то действительно виноват, то вы сможете от этого человека получить поддержку. Если с вами работает менеджер, которого снимут, в случае провала проекта, вы сможете ему объяснить, что «есть угроза», и он вам поможет.

Т.е. вопрос скорее звучит «кто виноват кроме меня»?

Это вопрос несколько в будующем — «кто будет виноват в крахе?»

Когда дедлайн?

Вопрос менее критичный. Если вы Blizzard, вам наверное все равно, вы и так опережаете рынок много лет.

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

Когда у вас дедлайн сколь угодно далеко, то проект может сьесть сколь угодно много денег. Это значит, он может оказаться сколь угодно экономически бессмысленнен.

Так что если дедлайна нет, то тоже есть повод задуматься.

Create a Product Definition Statement

Теперь таки поговорим о том, как все-таки сделать успешный проект. Позволю себе процитировать заголовок из руководства для разработчиков айфона. «Формулируйте что вы делаете, для кого вы делаете и что именно».

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

Что делать?

Когда у вас есть определение того, что вы сделали, это помогает вам не тратить время на пустые обсуждения. Например, мы делали проект для Министерства экономического развития Российской Федерации. И нам нужно было построить модель экономического развития регионов по 17 параметрам. Параметры совершенно от балды, мы в них ничего не понимали. Неясно было совершенно, что делать. Я предложил простую модель — «мы будем суммировать эти параметры с произвольными коэффициентами». Это абсолютно понятная модель, которую мы назвали «СуперСумматор».

Дали возможность пользователям менять коэффициенты, и смотреть при этом, какой регион, при каких коэффициентах выходит в топ. Мы ни минуты не спорили о том, что мы делаем. Мы это сразу понимали. Мы выпустили продукт с идеальным качеством.

По функциональности были небольшие замечания, но они никого не волновали.

Сопротивление бесполезно

Чем еще полезно иметь цель? Вы можете преодолевать сопротивление!

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

Был против того чтобы ездить согласовывать требования, был против того, чтобы запускать разработку, был против того, чтобы внедрять. Но так как была четкая цель, все равно все получилось.

The Joel Test: 12 Steps to Better Code

Давайте поговорим о процессах. Был такой, вернее есть такой человек, Joel Spolsky, который сделал для нас stackoverflow.com.

И он десять лет назад, написал статью «The Joel Test: 12 Steps to Better Code», в которой изложил по пунктам критерии нормального процесса разработки.

Давайте спросим себя, как отреагировала индустрия на статью Джоэля Спольски?

Индустрия положила большой болт на статью Джоэла.

Вы приходите в новый проект, там нет багтрекера.

«У вас нет багтрекера, да как же так? — А нет и нет, нам все равно, мы такие.».

Все, полная автономность. Я сейчас позволю себе немного творчески пересказать идеи Джоэла, но с точки зрения реальности.

Процесс

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

Wiki должен победить

Есть хороший метод, как решить эту проблему. Нужно использовать Wiki.

Вики используется личным примером, в него пишутся тексты, просите коллег писать,… есть успешные примеры, когда вики успешно запускается, и успешно развивается.

И в итоге, получаются спецификации, практически в том виде, в том формате, про который писал Джоел, у него есть несколько статей, о том, как писать спецификации.

«Wiki должен победить» — кого он должен победить? Обычно, он должен победить Sharepoint. Это такое большое хранилище документов, в него менеджеры иногда кладут вордовый документ. Кладут вордовый документ, потом его пробуют прочитать. Говорят «что-то ничего непонятно вообще, ерунда какая-то». Менеджер говорит — «ОК, ребята, я понял, действительно ничего не понятно, много вопросов, я перепишу».

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

Стас Фомин: Возможно, вас заинтересуют

успешные кейсы использования вики-систем:

• Knowledge Management: От Склада к Потоку
• MediaWiki — Серебряная пуля или швейцарский нож?

Из зала — а у нас обратный пример. Вики умер, а шарепоинт победил.

Это удивительно.

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

Вы справились, вы молодцы, но вот реальный программист… А если линуксоид? Он даже толком не подконнектится, он скачать документ еще сможет, а отредактировать уже нет.

Вики гораздо проще в редактировании документов!

Исправляйте баги

Этот слайд обусловлен глубокими личными переживаниями. Что будет, если вы будете исправлять баги?

Во-первых, вы получите уважение коллег! «Яша исправляет баги… , подумаешь… » — угу, не очень полезная деятельность.

Во-вторых, вас могут легко уволить! Вот вы, пишите какую-то компоненту, и написали ее из багов. Все, она работает, вас можно уволить. Так бывает, я знаю.

Третий момент — вы приходите на интервью, вас спрашивают, «что вы сделали? — я исправлял баги… — а делали то что?». Вот и все. Иди нафиг, нам нужны люди, которые без багов пишут.

Вы может и не свои баги исправляли, но вот на интервью бывает грустно.

Зачем же все-таки исправлять? Дело в том, что когда вы исправляете баги, вы все-таки делаете свое приложение лучше. И иногда эффект бывает неожиданным. Вы получаете больше, чем ожидаете.

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

Другой момент — иногда реально баги нужно править. Реальный пример — приходит ко мне начальник, и говорит «через две недели релиз, а у нас одни баги… релиз все-таки, надо бы поправить…». Ну ничего, переписал потихонечку, за две недели.

Третий момент — вот смотрите, есть айфон. В принципе, Nokia, HTC, Microsoft могут сделать девайс, который будет конкурентным по любым параметрам. Цену могут занизить, дисплей поставить, не хуже, по крайней мере, процессор большой поставить, акселерометр, совершенно не проблема. Что они не могут сделать? Они не могут сделать платформу, которая не будет глючить. Т.е. сделать без багов, это очень тяжело. Это реально становится конкурентным преимуществом.

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

А написать приложение с багами, может любой студент, это не фокус.

Как быстро вы исправите опечатку?

Этот следующий слайд, он про то, чтобы у вас был процесс разработки программного обеспечения. Т.е. вы должны понимать, как выпускать релизы.

Допустим такую ситуацию — вы выпускаете релизы раз в год. Что это означает? Это означает, что те люди, которые выпускали прошлый релиз, покинули компанию.

И вы начинаете выпускать релиз. Вы не понимаете, как это делать. Вы это делаете впервые. Естественно, у вас получается плохо. Поэтому релиз вы выпускаете не раз в год, а раз в два.

Стас Фомин: См. видеорассказ

о трехлетнем цикле выпуска продуктов.

Один год вы что-то разрабатываете, а потом еще год допиливаете, чтобы как-то выпустить.

Иногда это кончается сверху, и вы не выпускаете релиз вообще.

Теория

Это мы поговорили об общей какой-то инфраструктуре, но если вы хотите работать эффективно, вам нужны какие-то теоретические знания. Я бы хотел посоветовать почитать вам пару книг, первая из них это рефакторинг Мартина Фаулера, которая изменила мою жизнь — я сильно прибавил в кодировании после ее прочтения.

Но сейчас я хочу остановится на ее названии, вернее подзаголовке — «улучшение существующего кода». В чем ведь революционная идея рефакторинга? В том, что теперь мы код не выбрасываем, мы его улучшаем.

Теперь мы не говорим о том, что мы сейчас придем и напишем вторую версию кода заново, и она будет более правильная, мы берем существующую версию и начинаем ее дорабатывать. И постепенно дорабатывая, мы получаем более хороший результат.

И теперь, программное обеспечение делается именно так. Никто не делает сразу идеальный продукт, который потом никто не трогает. Все теперь сначала делают первую версию, потом смотрят на реакцию пользователей и дорабатывают.

Т.е. теперь программное обеспечение не столько разрабатывается, сколько улучшается существующее. И начальная разработка, она может длится год. А доработка может длится пять, десять лет, в зависимости от того, насколько ваш продукт успешен. Чем более продукт успешен, тем дольше длится доработка.

Другая книга — «Effective Java», рекомендуется читать второе издание, оно просто по Java 5, более актуальное.

Кирпичики

Асинхронная обработка задач

• http://www.telamon.ru/articles/async.html