Всем привет. Это снова «Без слайдов», и на этот раз у меня в гостях побывал легендарный Дмитрий Завалишин, известный всем как один из создателей Яндекс.Гуру (предшественник Яндекс.Маркета), основатель группы компаний DZ Systems и автор операционной системы Фантом.



О чем мы поговорили:

• кем Дмитрий себя сегодня ощущает: бизнесменом или айтишником;
• какие ниши заняли мобильные и веб-приложения в современной жизни;
• что такое горизонтальные и вертикальные рынки;
• чем отличается бизнес по разработке для этих рынков, и чем отличаются коробочные решения от кастомных;
• как можно быстро оценивать клиентов по трем параметрам;
• как найти хорошие кадры на проект;
• почему Agile — это беда для российского рынка разработки;
• наконец, как сделать ваших заказчиков счастливыми.

Все это — в традиционном видеоинтервью:



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

Enjoy!

Говорить без помощи слайдов

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

— Я очень люблю без слайдов выступать, потому что, как мне кажется, я неплохо обычно говорю. У меня есть картина мира, которую я хочу изложить, а слайды в известной степени этому мешают, потому что ты вынужден следовать их логике. А когда ты говоришь, движешься в процессе, то возникают новые идеи. Иногда хочешь отвлечься в сторону или поменять местами какие-то куски… И очень часто у меня получается, что я весь свой доклад рассказываю, показав только первую половину слайдов. А остальные просто пролистываю со словами: «Ну, это я уже рассказал, это я тоже уже рассказал, поехали дальше». Я не умею идеально делать презентации — давать 5 слайдов, на которых 5 картинок.

— Метафоры?

— Да. Графика или диаграммы, которые действительно показывают то, что сложно рассказать. Хотя на самом деле совсем идеальная картина – это блэкборд (школьная доска и мел) или флипчарт и карандашик. Потому что обычно надо нарисовать пару квадратиков со стрелочками, показать взаимоотношения сущностей какие-нибудь. Для меня, наверное это было бы самое комфортное.

Про свою роль в компании и жизни

— Но сегодня мы тебе даже карандаша не дадим. Расскажи лучше, кем ты себя ощущаешь? Ты бизнесмен, айтишник, программист или кто-то еще?

— Знаешь, бизнесмен – это очень абстрактная штука. Ведь в английском языке это просто «деловой человек». А в русском это слово обладает некоторым избыточным и специфическим флёром. И к тому же мало что несёт по смыслу.

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

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

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

Совершенно банальный пример: если грубо разделить компанию на части, то получим продажи и производство. И ты приходишь к продажам, говоришь: «Ребята, у нас с вами план на следующий год вот такой». Продажи начинают по этому плану продавать. Возвращаются и говорят: «Ну, мы заключили вот такую большую кучу контрактов». А производство тут говорит: «Ой, а мы столько сделать не можем. У нас не хватает сотрудников»… Причем, не просто абстрактных сотрудников, а специалистов в отдельных областях, проектных менеджеров, аналитиков. И ты должен выстроить всю структуру команды так, чтобы тебе хватило компетенций и рабочих рук на безболезненное прохождение всего процесса от начала и до конца. И это большая часть жизни.

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

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

Любое движение в сторону новых технологий, принятие решений по поводу того, что мы развиваем, а что нет. Мы же компания, в основном, производственная, в отличие от многих компаний в России мы пишем софт, а не внедряем западные коробки.

Про мобильные приложения vs. веб-приложения

— Давай чуть подробнее о том, чем вы занимаетесь.

Мы конкретно под заказчика с нуля создаём то, что ему нужно. В этом тоже есть определённая специфика, нужно понимание того, какие темы будут развиваться. Вот простой и очень грубый пример: некоторое время назад было не ясно, что на мобильном устройстве «правильно» делать — веб-приложения, которые оптимизировались под мобильное разрешение или нативные приложения.

— Ну, ответ-то мы теперь уже знаем — что все зависит просто от юзкейса…

— На самом деле я считаю, что приложения в целом выиграли.

— Если ты каждый день пользуешься, то конечно. Любые доли задержки, которые тебе веб даёт – всё, это невозможно.

— А это, кстати, тоже очень интересная, интересная ситуация. Смотри, мне кажется, что на самом деле в мобильном устройстве тоже случилось такое постижение некоторого дзена. Смотри, простой пример — есть два направлени: банки и ритейл (e-commerce).

В банках мобильные приложения — это уже и альфа, и омега и вообще всё. То есть, можешь просто запросто хоронить традиционную банковскую систему. В банке остались только back office и мобильное приложение. Всё остальное уже исчезло. И в будущем останется только у сбербанков, в которые бабушки ходят, и пока в них ходят эти бабушки…

— Ну веб же, наверное, тоже живой?

— Едва-едва. Практически полностью всё ушло в мобильные приложения.

— Все эти бесконечные реквизиты вбивать вручную на клавиатуре…

— А сейчас по-другому делают. Используют машиночитаемые документы, шрихкоды, QR-коды…
И на сегодня банка без мобильного приложения просто нет. А всё остальное умирает. И ритейл, e-commerce. Кстати, если говорить про автоматизацию, уход в электронику бизнес-процесса, то в e-commerce он очень давно случился. Банки, вообще говоря, позже за этим пришли. В e-commerce это случилось уже 15 лет назад.

Но в e-commerce с мобильными приложениями всё очень плохо. Не живут.

— А почему?

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

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

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

— Есть юзкейсы, когда ты хочешь, например, какую-то фичу быстро заделиверить на все устройства. Тут веб быстрее справляется — выложил на сервер и готово. А когда ты выкладываешь своё приложение в Android Market или в AppStore, то у тебя есть две или три недели на то, чтобы его до ума довести. И ты взял, WebView внутри сделал, и вот у тебя возможность обновления на лету.

— С вебом есть куча других проблем. Например, никакой оффлайновой работы. Хотя мы, в общем, живём в коммуницированном мире, и человек в онлайне почти 100 процентов времени, но по факту…
— Всегда есть еще метро или севшие батарейки.

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

Про кастомные и коробочные решения

— И это, наверное, более-менее правильная тактика.

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

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

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

У тебя, условно, есть широкий дешёвый рынок и есть вертикальный рынок. Конечно же, нам интереснее работать на вертикальном рынке, на рынке уникальных крупных клиентов, которым нужно в основном что-то кастомное…

— Типа Юлмарта?

— Да, типа Юлмарта, который рассматривает себя как абсолютно уникального игрока на рынке.

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

Знаешь, почему Яндекс победил всех? А потому что Волож когда всё это запускал, сказал: «Мы должны быть первыми. И это не обсуждается. У нас нет другой задачи, просто нет. Быть первыми – и всё тут. Мы туда идём».

И пришли. Нормально всё. То же самое у Юлмарт. И в такой позиции очевидно, что ты не можешь пользоваться инкубаторскими решениями просто потому, что ты должен быть уникальным…

— Но ты же не можешь быть во всём уникальным. То есть, наверное, можно некоторые инкубаторские решения использовать?

— Да, конечно. Особенно за сценой и в тех местах, которые не очень видны. Это, кстати, ещё и к вопросу о том, что у тебя есть куча бизнес-процессов. Какие-то из них — стабильные, банальные и реплицируемые. Они по всему бизнесу такого класса одинаковые. А есть бизнес-процессы, которые для тебя являются ключевыми, и которые ты продаешь именно как свою уникальность. Они, скорей всего, уникальные и есть. Есть точки оптимизации, которые тоже уникальные. Ну, и соответственно, когда ты работаешь как поставщик на этот рынок, ты должен уже примерно понимать, куда ты хочешь идти.

Хороший очень пример — Битрикс: хорошего среднего уровня — очень массовая штука. Но если ты начинаешь из неё делать уникальность, это становится дорого и бессмысленно. Потому что в итоге перепилишь почти весь Битрикс, у тебя получится в итоге всё равно кастомное решение, только нагруженное ограничениями самого Битрикса.

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

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

— Да. У нас бизнес-процесс в JIRA иногда модифицируется под конкретного клиента.

Если говорить про позиционирование на рынке, то и коробку, и вертикаль, понимают очень хорошо. Я разговаривал с людьми из Яндекса, которые жили на JIRA, а потом с неё стали уходить на самодельные решения. Почему? Потому что объём огромный, компания очень большая, JIRA не тянет.

Причём, как оказалось, у неё есть ограничения, которые нельзя снять, даже если ты её кастомизируешь активно. Они обратились в Atlassian: «Ребята, мы хотим решение под несколько тысяч пользователей». А Atlassian ответил: «Нет, мы не будем делать. Это не наш рынок. До свидания».

— Это вообще очень интересно. Потому что, казалось бы, огромный заказчик...

— Да.
—… с хорошими деньгами.

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

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

Я начал с того, что, когда мы занимались мобильным направлением, у нас появился e-Legion и встал вопрос, как действовать. Потому что на рынке мобильных приложений есть та же самая дихотомия. Есть компании- «генераторы мобильных приложений», которые синтезируют стандартное мобильное приложение.

— Стандартный интернет-банк: платежи, контрагенты, контакты, карта банкоматов. Оплата мобильного телефона.

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

— e-Legion, до того, как вошёл в холдинг DZ Systems, занимался горизонтальной разработкой?

— Нет. Он тоже в то время уже позиционировался в вертикальную сторону. Это то, почему мы так хорошо совпали и нас вполне устроило то, чем эта компания занимается. Когда e-Legion вошел в нашу группу компаний, конечно, принимали решение, нужно ли что-то менять. Но, в основном, оставили все, как было.

e-Legion и до этого был ориентирован на крупного уникального клиента с высоким качеством потребностей. Так что в этом месте мы совпали. Единственное, что мы поменяли — закрыли подразделение, которое работало в других направлениях, не мобильных, на западного заказчика.

Это, кстати, очень смешная ситуация. Когда это происходило, еще при старом курсе рубля, то наша работа на Западе стоила дороговато, а нам была не особо выгодна. И поэтому, когда мы проанализировали весь портфель заказов, оказалось, что западные заказчики у нас самые низкомаржинальные…

Про три параметра оценки клиента

— А как вы их оценивали?

У нас есть некоторая внутренняя шкала. Когда мы рассматриваем заказ какого-нибудь клиента, мы смотрим на три простых фактора: деньги, слава и компетенции. Мы смотрим на проект и думаем: «Что я с него получу?» — и ставишь три галочки. Если проект вменяемо маржинальный — ставим галочку. Если он позволит нам портфолио получить, которое потом следующие клиенты сочтут референтным, — ставим еще одну галочку. Если в процессе работы над проектом мы в себе разовьём какое-то хорошее новое знание, которого нам не хватало, — ставим последнюю галочку. И вот оказалось, что в проектах западных заказчиков все три галочки отсутствуют.

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

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

— Интересная история про вертикальный рынок. Я правильно понял, что этот термин значит, что у тебя есть небольшое количество крупных заказчиков, которым ты делаешь более-менее всё IT?
— Тут ситуация различается по группе компаний. Потому что в мобильной разработке обычно десятки проектов в год. А в DZ проектов единицы.

— Помнишь, как Михаил Самарин на Мобиусе рассказывал, что средний мобильный проект у них — это два человека на два месяца?

— Это маловато. У нас обычно пять человек на 3–6 месяцев. И потом есть аккаунты, на которых мы работаем годами. Банк Москвы, например. Мы много лет для него разрабатываем и постоянно развиваем это приложение. Наверное, когда-нибудь он, захочет поменять подрядчика и всё изменится.

Но в целом это именно такая аккаунтная ситуация, в которой мы закрываем некоторое направление для нашего заказчика долгосрочной работой. Есть, конечно, и разовые проекты. Например, Афимолл, торговый центр в Москве. Мы для него сделали внутреннее приложение, которое даёт навигацию по магазинам внутри ТЦ. Это, кстати, очень интересный опыт, особенно если возвратиться к вопросу про e-commerce в целом и про неудачу мобильных приложений в этой области. Мы делали несколько проектов по навигации в крупных торговых сетях, и это востребованный мобильный бизнес-кейс.

— Это для зоны, где покупатель? Или для склада?

— Да, это покупатель ставит себе мобильные приложения.

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

Про проблему поиска хороших кадров

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

— Это на самом деле большая проблема России вообще.

— Именно России? То есть, в мире нет такой проблемы?

— Безработица в России меньше, чем в мире, причём ощутимо так меньше. У нас, если я не ошибаюсь, там что-то в районе пяти процентов. А в Европе около 20 процентов. То есть, у нас ситуация предурацкая. У нас страна реально загружена работой выше головы. Рабочих рук не хватает. Развиваться экономике нужно, но развиваться ей некуда. Потому что некому это на самом деле делать. Ну, правда некому.

— А почему так вышло, и что с этим делать?

— Тут вот в Сочи проходил РИФ, из всех региональных РИФов самый ужасный. Я участвовал там в HR секции, рядом сидели коллеги из Headhunter и Superjob. И Владимирская. И в частности, я выкатил некоторую претензию со стороны заказчика. Я говорю: «Ребята, понимаете, я на самом деле сильно недоволен качеством хедхантинга в России, потому что вы же приводите абы что. На самом деле».

Я сижу, они разговаривают. «Вы понимаете, что когда вы между собой говорите «программист» как профессия, меня трясёт, потому что такой профессии нет». Внутри программиста ещё есть полторы тысячи нарезок, которые вообще никак не совместимы между собой. И обратиться к вам с задачей подобрать реально человека, который мне правда в эту позицию нужен – это нереально. Худо-бедно вы ещё можете по ключевым словам поискать.

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

— То есть, у них нет базы просто?

— Да-да-да. Видно, что какой-то профессиональной базы серьёзной у них нет вообще. Я тебе приведу пример. У нас есть несколько кейсов для тестирования аналитика. Ну, простой вопрос: «Мы с вами собираемся выпускать новый скайп. Назовите, мне пожалуйста, какие-нибудь задачи, которые мы должны положить в основу? Что люди с ним делают?». Знаешь, что отвечает аналитик? «Файлы передают».

— Ну, это серьёзно. Для аналитика.

— А ты понимаешь, в чём проблема, да? Проблема заключается в том, что для автомобиля нет юзкейса «ездить». Нет такого человека, который говорит «Давай ездить на автомобиле».

— Юзкейс — ехать куда-то.

— Поехать на дачу. Поехать на работу. Да хоть в магазин. Понимаешь, да?

Задача-то, она находится немножко за этим. Нет юзкейса «послать файл». Причём обрати внимание: так получилось, что я с некоторыми их них по скайпу как раз проводил собеседование. Понимаешь, и сидит аналитик, говорит со мной по скайпу, и не может вынуть мне юзкейс «провести по скайпу собеседование».
Понимаешь, да? И это неплохой аналитик. Он на самом деле, вообще говоря, неплохой. Это человек, который работал, писал документы. Я смотрел эти документы – они вменяемые.

У тебя же на CodeFreeze я рассказывал феерический кейс про домофон, у которого не было функции «не отпереть». То есть, его проектировал человек, который просто не знал, что есть альтернативные сценарии.

То же самое – я с аналитиком веду собеседование, говорю; «Ну, посмотрите, давайте мы с вами обсудим сетап из e-commerce. Скажем, доставку почтового заказа». Он описывает хорошо. Идеально описывает. Прямо правда проходит какие-то даже неочевидные вещи. Я говорю: «Ну, хорошо. А если не доставили?». Он: «Отправили и не доставили?». Я говорю: «Почему отправили? А если не отправили?».

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

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

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

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

Давно это было. Пришел заказ на описание бизнес-процессов в некоторой большой компании, интернет-провайдера. Они внедряли новую систему ERP. И мы для них выполняли чисто аналитическую работу. Наши аналитики написали огромные документы. Огромные. Итоговый документ был наклеен на стену, и полстены занимал. Бизнес-процессы ещё и текстом были расписаны. Мы правда подняли огромную работу, по которой была реализована система. Не нами. И когда эта система запустилась, и проработала месяц. А в конце месяца некая «тётя Лена из бухгалтерии» сказала: «А где же мой эксель? У нас был эксель, в который все вписывали, какие счета выставляются клиентам, а я в него потом заходила и подправляла для Васи и для Лены — у нас там с ними есть договорённости устные о том, что мы, там, для них делаем такую скидку. Я подправляла в этом экселе. Где он?».

А нигде. Нет его больше. Всё. До свидания. Это происходит в системе, и в ней нет места, где тётя Лена может влезть и что-то подправить. В чём же проблема? В том, что выявить наличие этого бизнес-процесса не представлялось возможным просто никак. Это не ошибка аналитиков, это просто имманентное свойство нашей Вселенной. Ты никогда не можешь гарантировать, что ты полностью покрыл всю карту знаний про определённую область. Просто потому, что не существует некоего инструмента верификации, что ты всё покрыл.

Эта тётя Лена, пока не пришёл день выставления счетов, просто не помнила, что она это делает. Она это делает на полном автомате. Когда её спрашивают, что она делает, это она просто не вспомнила. И никак это дело не закрывается. На эту тему пишутся книги, и предпринимается много усилий, но это я показал совсем уж уникальный кейс. За всю мою жизнь – а я, там, больше двадцати пяти лет этим занимаюсь – это был один такой случай, когда вскрылся процесс, который не удалось выявить. Но в целом систематика работы над требованиями, она именно про это. Про то, что если ты будешь ad hoc их собирать, как-то на колене и ситуативно, то ты очень много чего пропустишь. И то, что ты потом спроектируешь, оно окажется фрагментарное и дырявое по итогам.

Почему Agile — это беда для российского рынка разработки

— А что в области управления проектами?

— Очень похожая ситуация в управлении проектами. И победное шествие Agile по России — это просто беда на самом деле. Потому что за Agile в основном скрывают просто неумение делать по какому-то другому, не Agile, процессу.

Я как-то обсуждал это на конференции. Мне сказали: «Ну, хорошо, вы так ругаете Agile, но он же где-то точно применим, он точно совершенно существует». Так вот, он более применим в in-house, чем в заказной разработке. Он более применим в поддержке и развитии, чем в старте проекта, например. Потому что ключевые вещи, которые допускает agile, это

• а) очень большое доверие между исполнителем и поставщиком, и
• б) отсутствие задачи по глубокому проектированию.

Если не надо глубоко проектировать, то можно использовать Agile, потому что ты мало что сломаешь. Ну, в конце концов, если проект состоит из миллионов формочек по набиванию, то можно по Agile делать, потому что сломаешь две формочки, остальные двести от этого не сильно испортятся. А если ты делаешь большую сложную систему, то, недопроектировав её в одном месте, ты можешь порушить половину системы. И поэтому Agile там неприменим.

Когда тебе человек так отвечает и говорит, что Agile поэтому возможен, то да, можно соглашаться. И ещё очень хороший критерий – если тебе человек говорит: «Я это предлагаю делать по Agile». А ты спроси его: «А как это делать по RUP?». Если он тебе показал, рассказал, что по RUP он это тоже умеет делать, а потом объяснил, почему по RUP делать не надо, а по Agile надо (я утрирую), то ты можешь ему верить.

В 90 процентах случаев человек, который приходит с agile, RUP не знает вообще. Он выбирает Agile не потому, что это хорошо, а потому что просто больше ничего не умеет. Это массовая ситуация.

Про то, каким должен быть хороший проектный менеджер

—Cлушай, а это вообще интересный вопрос. Давай поговорим про менеджеров проектов. В этих областях тоже есть правила — PMBoK, ISO9000, CMMI…

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

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

Но вообще, менеджером проектов нужно родиться. Считаю, что project-менеджера научить нельзя. В человеке либо есть эта жилка, либо нет. Это внутренний драйв, некоторая энергетика, которая заставляет человека двигаться. Мы их называем «самодвижущиеся». Знаешь, есть люди, которых не надо снаружи как бы энергетизировать, чтобы они шли по проекту. Это важнее всего, конечно же. Всё остальное к этому уже добавляется. Потому что есть внутренние правила по артефактам, как проект должен быть так устроен.

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

— Например?

— Абсолютно банальная вещь. Еженедельный отчёт PM-a клиенту что должен включать?

— Я бы, наверное, сказал так: что сделали, что будем делать, какие есть проблемы. В таком ключе.

— Ты прямо попал стопроцентно. Это ровно и есть те три необходимые части, которые туда попадают. Что сделали на прошлой неделе, что стоит в плане на следующей неделе, и во что упираемся, что у нас в этом месте.

— Меня хорошо научили, значит.

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

Мы с тобой сейчас говорим про качество сотрудников, а есть ещё одна огромная проблема. Причём она в существенной степени российская. В мире сильно легче. Это качество заказчика.

— А что такое качество заказчика?

— До того, как запустить свою компанию, я совершенно сознательно пошёл к станку, в чужую компанию, большим менеджером проектов. И поработал вообще и в российской компании, и на Запад поработал. А потом поработал в американской компании тоже на Запад же. Так в западном этом мире заказной разработки, там заказчик и исполнитель – это как вилка и розетка. Прямо «чпок», и понеслась.

— То есть, у них одинаковое понимание мира какое-то?

— У них очень хорошее понимание того, как заказывать, что находится на стороне заказчика, а что должен исполнитель, и как оно клеится. То есть, грубо говоря, я приехал как исполнитель к заказчику в Лондон, и эти люди мгновенно показывают мне project plan.

Почему это важно? Во-первых, потому что на той стороне тоже PM, и я это вижу. У него тоже есть процесс, который я понимаю. Во-вторых, он показал мне в своём плане моё место и показал мне, в какие дедлайны с его стороны я реально упираюсь. И это для меня очень важно. Как любит говорить мой начальник производства, «если в проекте всё хорошо идёт, PM не нужен». То есть, PM нужен как раз для ситуации, когда всё плохо идёт.

Это именно решение проблем в проекте. А что такое решение проблем? Это в основном какие-то trade-off'ы. Это понимание того, где правда сделать нельзя, а где можно. Что ты можешь управляемо сдвинуть, а что ты не можешь управляемо сдвинуть. И это источник приоритета для тебя.

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

Есть и другие ситуации. Например, готовность аппаратуры под софты. Много разных связывающих вещей. Да, и понимание того, как именно они связываются, и понимание, как заказчик управляет своим проектом – потому что ты всегда являешься элементом в более крупном проекте своего заказчика. И это большая редкость.

И знаешь, что ещё удивительно? У нас в России есть такое массовое неуважение к госзаказчику. На самом деле в госзаказе качество управления проектом зачастую выше, чем в коммерческом заказчике.

— А почему?

— Не знаю.

— Это эмпирическое наблюдение?

— Да. Это просто я смотрю на ситуацию. Помню, как я 10 лет назад приехал в «Почту России», которую кто только ногами не пинал. И я посмотрел на внутренние рабочие документы их аналитиков. И я хочу тебе сказать, что только, наверное, лет через пять я дошёл до сопоставимого уровня. Хотя я этим очень серьёзно занимаюсь. То есть, там был высший класс. Документы были написаны на твёрдые пять баллов.
Ну, там есть, наверное, какие-то другие проблемы были.

— Очевидные.

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

Про то, как сделать заказчика счастливым

Дима, а как понять, за какой заказ браться, а за какой нет?

Когда приходит заказчик и говорит, что хочет что-то делать, то я ему задаю вопрос, который вскрывает очень многое на его стороне. Я говорю: «Ну, смотри, мы с тобой доделали проект. Прошел год. Ты сидишь в своем кабинете, смотришь на результаты и понимаешь, что счастлив. Скажи мне, какую линейку к какому месту ты приложишь, и какое значение ты должен увидеть, чтобы это «Я счастлив» осуществилось?». Если в этот момент он задумывается – гоните его. Он не знает, что он делает.

— Мне понравилась другая твоя история про вопрос заказчику. Про то, как он на этом сделает деньги.

— Это то же самое. Это тот же самый вопрос на самом деле. Не принципиально. Вопрос в том, где то место, в котором он испытает счастье через какое-то время И скажет тебе: «Да. Я этого хотел – я этого достиг».

— То есть, вариант «я через год заработал больше денег» — это лишь один из вариантов этого ответа?

— Это один из вариантов. Потому что есть разные ситуации.

Например, у тебя Олимпиада. Хотя это коммерческий проект, который должен окупаться, но у него есть бешеная PR-составляющая. И она, по большому счёту, дороже денег. И это все принимается как ответ на вопрос.

Это может быть и совершенно банальная ситуация. Заказчик скажет: «Я этот проект закрою – меня повысят». Окей. Приемлемо. Потому что тебе неважно, какая мотивация у твоего заказчика, но она должна быть, и ты должен понимать, что он тоже ляжет костьми, чтобы этого достичь. Потому что, одна из феерических проблем такой заказной разработки, когда ты со своей стороны делаешь всё, а со стороны заказчика – ни шатко, ни валко. То есть нахождение мотивированного профессионального драйвера этого процесса со стороны заказчика – категорическая и очень важная сторона.

Причём бывают ситуации феерические: когда он мотивирован, но не профессионален. И он много чего не понимает и не умеет на своей стороне, и это рушит проект. Ты можешь в этом месте быть идеален.

— А вы ему не пытаетесь помочь?

— Конечно, пытаемся. Но здесь тоже есть очень разные ситуации. Потому что бывали ситуации, когда запускаешь проект, начинаешь общаться с заказчиком: «Смотри, у тебя будет такая проблема. Давай, мол, мы здесь тебе поможем». Он тебе говорит: «Вы программисты? Идите программировать. Я здесь лучше вас разбираюсь. Не парьте мне мозг. Не мешайте». И что ты ему на это скажешь? У меня была ситуация, когда мы работали с заказчиком-мультимиллионером. Взрослый мальчик, сделавший большие деньги. И ты сейчас будешь ему рассказывать, как и где он ошибается… То есть, это проблема твоей значимости, которую ты ему должен нарисовать в этом месте, и как-то доказать свою правоту.

У нас была ситуация: большой e-commerce проект. Мы запускаемся, пишем с заказчиком требования. А это был стартап, площадка типа Яндекс Маркета, условно говоря. И мы заказчику говорим: «А ты знаешь что у Яндекса есть стандарт взаимодействия между магазином и площадкой; ты его прими, пожалуйста, и напиши, чтобы тебе его реализовали как инструмент». Заказчик отвечает: «Нет. Зачем он мне нужен?! Он плохо попадает под мои возможности. Нет, я свой хочу».

Мы говорим: «Твой не будут использовать. Не согласятся магазины для тебя делать специальную разработку, а эта у них есть. Это им включить две строки в конфигурацию. И сразу заработает». Заказчик все равно отказывается. Мы фиксируем техзадание. Своим сотрудникам я говорю: «Вы должны приложить все усилия для того, чтобы донести до заказчика, где он ошибается. Но когда он сказал «нет», это уже не ваше дело. Это его бизнес. Это его решение. Он за него отвечает. Вы только это «нет» от него примите. Чтобы вы чётко понимали – было написано «нет». «Да» — предложили, «нет» — отказался. Спасибо».

Сделали систему. Он её запускает. Конечно же, сто процентов магазинов ему говорят: «Да ты вообще в своём уме?! Ты кто вообще?! Да чтобы мы с тобой работали, ты нас должен поцеловать куда-нибудь ниже пояса». И он прибегает со словами: «Да, да, нам надо делать яндекс-маркетный формат. Что же вы мне не сказали?».

— Ты просто ушёл поржать в другую комнату?

— Да нет, я разозлился. Я в этот момент, конечно, просто разозлился. Я говорю: «Слушай, я лично к тебе приезжал и предупреждал. И у тебя документ есть, как все было».

И эта ситуация очень массовая, я про нее говорю непрерывно и постоянно на всех конференциях. Что умение помочь заказчику структурировать то, что он делает – это катастрофически важно. Потому что вы можете быть профессионалами и делать идеальную вещь, но если приоритеты заказчика были плохие…

Вот мысль, которую я пытаюсь заказчику донести: «Понимаешь, мы тебе делаем автомобиль, но ехать на нем тебе. И мы тебе можем сделать Феррари, а можем сделать трактор, БелАЗ. Это и то, и другое – автомобиль. И мы и то, и другое можем сделать идеально. Но если мы тебе построим БелАЗ, а ехать надо по хайвэю 200 км/ч, то… Мужик, ты уж постарайся про это подумать сейчас. Мы поможем тебе, но решение всё равно за тобой».

И это ещё вопрос управления приоритетами и вопрос управления всем объемом работ. Потому что это тоже стандартная проблема: ни у одного заказчика нет бесконечного количества денег. И всегда есть ключевые и второстепенные задачи. И я своим менеджерам проектов и аналитикам постоянно в голову вбиваю вот такую идею: «Смотрите, вы с заказчиком прошлись по всему объему работ проекта. Вы обрисовали техзадание, уже обрисовали юзкейсы, у вас есть какая-то сценарная картина составная. Дальше вы должны сделать принципиально важную вещь: заставить-заставить-заказчика, ногами его запинать, чтобы он разделил все на три приоритета: жизненно-необходимый, важный и желательный». И сразу объясним ему, что желательный мы, скорее всего, не делаем никогда, потому что будем этим жертвовать в пользу предыдущих двух приоритетов.

И стандартная ситуация, когда 90% проект уходят на критический приоритет, а остальные 5% на важный и желательный. Но так нельзя. И это надо объяснять. Причём я даже рисую, чтоб они понимали, что такое критический. Критический для автомобиля – это плоская железка, табуретка, руль, мотор, ни крыши и ни фар нет. Про музыку даже не говорю. Понимаешь, фар нет. То есть, это то, на чём можно реально тронуться и поехать. Ну, тормоза ещё нужны.

Всё. Больше ни-че-го. Ни дверей, ни мягкого кресла. Можно поехать? Можно.

Далее «важный» – это то, что дополняет это до основного бизнес-процесса. Это когда появляются сиденья. Какие-то! Ещё не мягкие. Это появляется крыша, фары. А желательный – это уже освещение салона, мягкие кресла, поясничные подпоры, все эти приятные вещи, которые мы очень хотели бы иметь. Но совершенно точно, что если их не будет, мы всё равно доедем, и в целом доедем даже, там, без особенных страданий. Потому что это твой инструмент движения по проекту работы внутри компании и команды, понимания того, как они должны двигаться. Где очень жёстко, а где что может быть как-то управляемо.

---

Дополнительные видеоматериалы:

• Пределы Digital Zone — интервью Александру Плющеву
• Успешные проекты: где стелить солому? — выступление на CodeFreeze
• Юлмарт.Эксперт — рассказ о новой экспертной системе в Ulmart