Макс Дорофеев: «Цель проекта — не разработать ПО в срок, а решить проблему заказчика»

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

Начало пути и успешные провалы

— Как вышло, что ты начал управлять проектами?

— 19 лет назад мне попалась книжка Питера Абеля «Программирование на языке Ассемблера». Мне было 12. Я выучил двоичную и шестнадцатеричную системы счисления (чем эпатировал учительницу по математике), а потом пошёл в детский компьютерный клуб. Меня посадили за старый Commodore и сказали: программируй! Ни курсов, ни обучения. Я сел и начал программировать. Подглядывал за ребятами, выдумывал себе задачки. Потом написал на Паскале первую игрушку.

Через пару лет папин знакомый спросил, можно ли сделать так, чтобы отчеты для его фирмы составлял компьютер? Я подумал: фигли! Взял и сделал. Помучался где-то полгода, заработал целых 500 долларов, купил себе компьютер XT. Так всё и началось.

— И ты стал программистом.

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

Потом я окончил школу, поступил в МГУ и вскоре оказался в компании, занимавшейся бортовым ПО для гражданской авиации. И в 23 года мысль про команду вернулась: захотелось иметь дополнительные руки и мозги, программировать не в одиночку, тихо замкнувшись, а кучкой людей. Я пошел в книжный магазин, думая: «Управление командой называется менеджмент — идём к полке с книжками про менеджмент и берём что-нибудь оттуда».

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

Я прочитал её, затем книжку Гаррингтона Эмерсона «12 принципов производительности» (1909 года!) и начал, как мне тогда казалось, разбираться в теме. Вдруг стало очевидным, что мой руководитель совершает ошибки. Я начал ему говорить: чувак, ты делаешь не так, давай мы сейчас эту задачу распилим, сделаем по-моему, тогда мы её поставим раньше и успеем сделать ещё что-нибудь. В общем, начал его учить жизни.

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

Раньше я верил: чтобы стать менеджером, достаточно нарисовать колбаски на диаграмме Ганта в MS Project. Я нарисовал все колбаски, но через неделю ни одна из них не совпала с реальностью. Я сказал: «Чёрт!» и нарисовал другие колбаски. Через неделю опять ничего не совпало. Тогда я понял, что ничего не понимаю, и начал читать книжки, много книжек, пытаясь разобраться, в чём дело. На физфаке МГУ нас всегда учили: «Если что-то не получается, не изобретайте ничего, всё изобретено до вас, читайте много книжек».

Одной из книг был «Человеческий фактор» Тома ДеМарко с тайным посылом "любите людей". Была хорошая книжка Джо Мараско «Фронтовые очерки». Её вымышленный персонаж руководил шахтами, где добывали руду. Затем, по замыслу автора, герой начал управлять программными проектами и учить своего коллегу мудростям управления на примере управления шахтами. В этой книге попадалась математика, какие-то формулки. Я подумал: ага, можно использовать изученное в универе - математику! Оказалось, что между математикой, физикой и управлением проектами очень много общих вещей.

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

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

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

Я учился, учился и учился. Следовал правилу, которое меня реально спасло: час в день читать книжку - что бы ни происходило вокруг. Читал книжки по менеджменту и по математике (для аспирантуры) и думал, как это можно совместить. В 2008 году сделал слайдкаст, в котором представил матмодельку по предсказанию сроков:

C тех пор я часто делаю презентации и скринкасты, делюсь своими находками с коллегами и начинающими.

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

Еще одно правило: если ты чего-то выдумал, тебе это кажется правильным, посмотри, не выдумал ли кто-то это до тебя. Если никто не выдумал, то ты либо ошибся, либо плохо искал.

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

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

— Да. Это оставило отпечаток и на моих программистских навыках. Будучи менеджером, я регулярно прохожу «кодотерапию». У меня есть пара проектиков, которые я программирую — просто для того, чтобы понимать, что делают мои ребята, чтобы говорить с ними на одном языке.

Моя концепция разработки – «всё уже написано до нас». Что это означает? Сейчас, например, я разрабатываю маленький прикольный сервис, который помнит мою программу тренировок и рассчитывает профиль задействованных мышц (http://musculejournal.ru/). Так вот: моих там, наверное, экранов пять кода. Когда требуется, например, drag’n’drop-компонент, я не начинаю его писать сам, а думаю: «где бы он мог еще использоваться?» А, например, в доске управления задачами или в каком-нибудь менеджерском инструменте. Иду на SourceForge, на Codeplex, и действительно нахожу десяток таких проектов. Восемь из них не подходят по языку, по платформе, а один-два вполне годятся. Аккуратно вырезаю кусочек функционала и использую, если лицензия позволяет.

— Куда ты пошел работать после авиации?

— В какой-то момент мне захотелось развиваться и учить новые технологии, которых в самолётах не было: HTML, паттерны проектирования, MVC, и, хотя на прежней работе всё было хорошо и дружно, я ушел в компанию «Аурига».

Там я сразу столкнулся с жесткими реалиями Business Application Development. Один из проектов был для крупной западной компании, мы автоматизировали систему складского учета. Сейчас я понимаю, что этот проект по большому счету стал моим позором. Мы взяли с заказчика деньги и сделали ему примерно в срок то, что он попросил. Оно работало, ошибок не было (какие-то практики из разработки самолетного софта я туда перетащил и они очень помогли). Мы демонстрировали функционал заказчику раз в неделю и нигде ни разу не выскочило ошибочки — этим я гордился.

Но я более чем уверен: они сейчас это не используют. И теперь, работая в IT-департаменте Лаборатории, я понимаю, почему. Надо было ещё до того, как мы начали обсуждать детали проекта и функциональные требования, задать заказчику вопрос: зачем вам мы? Почему вы сами не можете сделать?

Я ведь знал, что у заказчика большой штат собственных программистов. Тогда меня не насторожило, что одна программистская контора приходит к другой программистской конторе заказывать код. На самом деле к нам пришли хозяйственники, которых собственное IT-подразделение послало в задницу: мол, не нужно ничего разрабатывать, потому что скоро в их системе появится глобальный супер-мега-дорогущий модуль, которые все проблемы решит. Они не поверили, нашли где-то немного денег, пришли к нам – а мы разработали.

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

С точки зрения бизнеса: моя компания деньги получила? Получила. Заказ выполнили? Выполнили. В срок? В срок. Бюджет не превысили? Не превысили. Вроде всё хорошо.

— Но ты все равно почувствовал фэйл.

— Фэйл, да. Острое ощущение неудачи пришло где-то через 3 месяца после завершения этого проекта, когда я понял, что не задают вопросов по тонкостям и нюансам. А твердая уверенность в фэйле пришла уже, когда я осознал IT-шную специфику большой компании.

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

— И за это ты чувствуешь в себе ответственность?

— ДА! Но мне кажется, что эту ответственность ощущать должны все. Формально её в лучшем случае несет один человек, но это не означает, что все остальные должны забывать о цели проекта.

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

Года 3-4 назад я думал, что все причины фэйлов сконцентрированы именно на этапе разработки, потому что она запутанна и непредсказуема. Сейчас я думаю, что они равномерно размазаны по всем этапам, от идеи до вывода софтины из эксплуатации. На каждом этапе – свои грабли.

Один день в Лаборатории Касперского

— Какие проекты ведет твой отдел в Лаборатории?

— Я работаю в IT-подразделении, руковожу отделом разработки. Продуктами для конечного потребителя занимается департамент исследований и разработки (R&D), а мы помогаем работе компании. Железки, инфраструктура, внутренняя автоматизация, HR, бухгалтерия, финансы и прочая хрень, плюс мы делаем сервисы, которые поддерживают жизнедеятельность продукта компании.

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

— Из чего состоит сейчас твой рабочий день?

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

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

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

— То, что считают важным другие.

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

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

Обошли владения, а дальше смотрим по списку задач. Как выглядит мой список? Это зависит от того, какая основная тема у нас сейчас выбрана в команде управленцев. В данный момент мы внедряем управление проектами по методу теории ограничений. И достаточно много времени каждый день отъедает так называемое обследование – надо помочь менеджеру проекта внедрения опросить сотрудников, получить нужную информацию, рассказать свое видение.

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

Counter Strike на собеседованиях

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

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

— Как научиться выбирать людей? Только опытом?

— Не знаю, я использую чувство жопы.

— То есть интуицию, порожденную опытом?

— Чувство жопы. Сидишь и смотришь на человека: видишь ты его в команде или не видишь. И я для себя сам решил – обнаружил, набив пару шишек – технические навыки для программиста это всё-таки не главное. Главное – впишется он в команду или нет. Если он чего-то не знает, парни научат. Если он с ними подружится, всё будет замечательно.

Но и тут главное не перестараться. В свое время ещё в самолётной компании мы взяли человечка – дружелюбный, замечательный, но из-за него полкоманды стало играть в Starcraft по полдня. Это, конечно, интересно — социализация и все такое, но работать тоже иногда нужно.

Про игры, впрочем, у меня есть теория: как человек играет, так он и работает; по технике игры в Counter Strike, Quake или Starcraft можно понять, готов человек войти в команду, или нет.

— Командная игра.

— Да. Если человечек в «Контре» берет «слона», шкерится в углу и пытается застрелить врага в затылок – он не наш боец. Если он до этого ни разу не играл, но смело с пистолетом рвется в бой, получает пулю в лоб, умирает первым, в следующий раунд беред пистолет, бежит вперед, получает пулю в лоб, умирает первым и так пять раз – он может чего-то стоить. И в Starcraft есть стратегия — застроиться на своей базе, закрыться вообще от внешнего мира и тихо строить battlecruiser – ну, вот люди так и работают, они садятся за свой комп, погружаются в свою проблему и, чтобы лишний раз не спрашивать, обрастают проблемами только сильнее. А бывают люди, которые первые 2 собачки пошлют тебе на помощь, и такие ребята очень ценны. Они попадаются не часто, но их сразу видно.

Поэтому, наверное, на собеседованиях было бы неплохо играть. Хотя я этого никогда не делал. Но когда здесь я набирал себе первых программистов, то собеседование вдвоём с моим верным товарищем проводили так: я приносил ноутбук, подключенный по SSH к консоли нашего вебсервера. Мы брали вполне боевую задачу из нашего списка, давали, не глядя на резюме, задачу и доступ к серверу. Говорили: вот у тебя компьютер, задача и мы, — два бойца, которые что-то могут подсказать, — и вот ссылочка на документацию. Понятно, что мы симулируем настоящую работу, поэтому попутно будем говорить, отвлекать, травить анекдоты, а ты работай.

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

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

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

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

Продолжение: убеждаем программистов, что маркетолог — не чмо в галстуке, и навсегда отучаем менеджера требовать недельные отчёты. А также: каверзные вопросы для собеседования и книги, помогающие на них ответить. →