Меню
Войти
Максим Дорофеев — руководитель отдела разработки в Лаборатории Касперского (на момент взятия интервью - прим. Смартии), ироничный профессионал, обожающий делиться знаниями и опытом. Мы обсудили управление проектами по разработке программного обеспечения: полезные книги, квантовые теории и пользу игры Starcraft на собеседованиях программистов.
— Как вышло, что ты начал управлять проектами?
— 19 лет назад мне попалась книжка Питера Абеля «Программирование на языке Ассемблера». Мне было 12. Я выучил двоичную и шестнадцатеричную системы исчисления (чем эпатировал учительницу по математике), а потом пошёл в детский компьютерный клуб. Меня посадили за старый Commodore и сказали: программируй! Ни курсов, ни обучения. Я сел и начал программировать.
Подглядывал за ребятами, выдумывал себе задачки. Потом написал на Паскале первую игрушку.
Через пару лет папин знакомый спросил, можно ли сделать так, чтобы отчеты для его фирмы составлял компьютер? Я подумал: фигли! Взял и сделал. Помучался где-то полгода, заработал целых 500 долларов, купил себе компьютер XT. Так всё и началось.
— И ты стал программистом.
— Да. Это было здорово: берёшь компьютер и заставляешь его делать то, что хочется. Но одному было тяжело. Поэтому я начал задумываться о том, как бы делать что-то при помощи компьютера, но быстрее и больше? Для этого явно нужна была команда.
Потом я окончил школу, поступил в МГУ и вскоре оказался в компании, занимавшейся бортовым ПО для гражданской авиации. И в 23 года мысль про команду вернулась: захотелось иметь дополнительные руки и мозги, программировать не в одиночку, тихо замкнувшись, а кучкой людей. Я пошел в книжный магазин, думая: «Управление командой называется менеджмент — идём к полке с книжками про менеджмент и берём что-нибудь оттуда».
Мне очень повезло: в руки попалась книжка Питера Друкера «Практика менеджмента». Найти хорошую книгу по этой теме очень тяжело — и та книга была хорошая. Я прочитал её, затем книжку Гаррингтона Эмерсона «12 принципов производительности» (1909 года!) и начал, как мне тогда казалось, разбираться в теме. Вдруг стало очевидным, что мой руководитель совершает ошибки.
Я начал ему говорить: чувак, ты делаешь не так, давай мы сейчас эту задачу распилим, сделаем по-моему, тогда мы её поставим раньше и успеем сделать ещё что-нибудь. В общем, начал его учить жизни.
Мне снова повезло. Молодой и горячий начальник сказал бы: «Иди отсюда, молодой и глупый программист, начальнику виднее». Тот поступил умнее: поручил вести проект. Я был вне себя от радости, но, взявшись за управление, быстро начал понимать, откуда росли ноги у неправильных решений — многие из них казались мне неправильными, потому что я не знал всей правды целиком.
Раньше я верил: чтобы стать менеджером, достаточно нарисовать колбаски на диаграмме Ганта в MS Project. Я нарисовал все колбаски, но через неделю ни одна из них не совпала с реальностью. Я сказал: «Чёрт!» и нарисовал другие колбаски. Через неделю опять ничего не совпало. Тогда я понял, что ничего не понимаю, и начал читать книжки, много книжек, пытаясь разобраться, в чём дело. На физфаке МГУ нас всегда учили: «Если что-то не получается, не изобретайте ничего, всё изобретено до вас, читайте много книжек».
Одной из книг был «Человеческий фактор» Тома ДеМарко с тайным посылом "любите людей". Была хорошая книжка Джо Мараско «Фронтовые очерки». Её вымышленный персонаж руководил шахтами, где добывали руду. Затем, по замыслу автора, герой начал управлять программными проектами и учить своего коллегу мудростям управления на примере управления шахтами. В этой книге попадалась математика, какие-то формулки. Я подумал: ага, можно использовать изученное в универе — математику! Оказалось, что между математикой, физикой и управлением проектами очень много общих вещей.
Например, принцип неопределенности. В физике он носит имя Гейзенберга и гласит: «достоверно зная положение квантовой частицы, мы не можем точно измерить её скорость, и наоборот». Вот аналогия в проектной работе — если начальство в каждый момент времени хочет досконально знать состояние дел в проекте, работа останавливается: менеджеру приходится все время приходить к программистам и интересоваться, как идут дела.
Выясняя статус проекта, я получаю информацию. Но при этом мешаю человеку работать, он тратит время на разговор со мной, а после моего ухода вынужден сидеть и вспоминать, на чём прервался.
Короче говоря, я трачу его время, а значит — плачу деньги.
Отсюда у меня появилась управленческая концепция: любая информация стоит денег, поэтому каждый раз надо думать, какую информацию ты хочешь получить, сколько она стоит и готов ли ты заплатить эту сумму.
Я учился, учился и учился. Следовал правилу, которое меня реально спасло: час в день читать книжку - что бы ни происходило вокруг. Читал книжки по менеджменту и по математике (для аспирантуры) и думал, как это можно совместить. В 2008 году сделал слайдкаст, в котором представил матмодельку по предсказанию сроков:
C тех пор я часто делаю презентации и скринкасты, делюсь своими находками с коллегами и начинающими.
Я люблю тачки, поэтому прочитал много книжек о компании Toyota и её принципах бережливого производства. Оказалось, их можно использовать и при разработке ПО, и это не моя находка: есть очень хорошая книга Мэри Поппендик «Бережливое производство программного обеспечения: от идеи до прибыли».
Еще одно правило: если ты чего-то выдумал, тебе это кажется правильным, посмотри, не выдумал ли кто-то это до тебя. Если никто не выдумал, то ты либо ошибся, либо плохо искал.
Самый большой облом был в аспирантуре, когда я начал писать диссертацию про образование гидродинамических потоков вблизи колеблющихся тел, выдумал формулу, выдумал модель, а потом случайно обнаружил, что лет за 60 до моего рождения кто-то у меня эту идею уже украл. Было обидно.
— Найдя предшественника, можно сразу посмотреть, до чего он дошел в конце, чтобы не проходить весь путь самому?
— Да. Это оставило отпечаток и на моих программистских навыках. Будучи менеджером, я регулярно прохожу «кодотерапию». У меня есть пара проектиков, которые я программирую — просто для того, чтобы понимать, что делают мои ребята, чтобы говорить с ними на одном языке.
Моя концепция разработки – «всё уже написано до нас». Что это означает? Сейчас, например, я разрабатываю маленький прикольный сервис, который помнит мою программу тренировок и рассчитывает профиль задействованных мышц. Так вот: моих там, наверное, экранов пять кода. Когда требуется, например, drag’n’drop-компонент, я не начинаю его писать сам, а думаю: «где бы он мог еще использоваться?» А, например, в доске управления задачами или в каком-нибудь менеджерском инструменте. Иду на SourceForge, на Codeplex, и действительно нахожу десяток таких проектов. Восемь из них не подходят по языку, по платформе, а один-два вполне годятся. Аккуратно вырезаю кусочек функционала и использую, если лицензия позволяет.
— Куда ты пошел работать после авиации?
Программисты и дизайнеры строят Интернет, но без информационных архитекторов-проектировщиков жить в нем было бы невыносимо.
Там я сразу столкнулся с жесткими реалиями 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 минут без документации. Это просто потрясло: неизвестный веб-сервер, непонятно когда и кем написанный фреймворк, а он взял и разобрался! Этот человек до сих пор продолжает радовать.
И ещё один персонаж пришел на собеседование в косухе, ошейнике, заклепках, с черными волосами до колен. Внешность оказалась обманчива, мы увидели, что парень умный. И опять большое спасибо «подходу боевой задачи» — без него так бы и хохмили над внешним видом.
Мы травим байки, анекдоты, отвлекаем и смотрим: если человек раздражается - это сигнал опасности. Если не раздражается, а тоже какие-нибудь анекдоты травит, то это хорошо, а если еще и с задачей справился – вообще отлично.
Как набирать менеджеров, я сейчас не скажу, хотя передо мной стоит именно такая задача. Мы сейчас будем набирать именно менеджеров проектов. Как – не знаю и пока буду ориентироваться только на чувство жопы и на мнение человека, которого возьму с собой.
Как подружить людей и цифры
— Обычно менеджеры проектов много времени проводят в таск-трекере. Какие у тебя отношения с таск-трекерами?
— Я люблю их, я их внедряю! Таск-трекеры показывают объективную информацию согласно твоей модели управления: циферки. Менеджеры их любят очень, эти циферки. Как говорится, людей надо уважать, а доверять все-таки цифрам и фактам. Но не люблю бестолкового их использования.
Многие — очень часто встречал — берут таск-трекер, зря наворачивают процесс, усложняют workflow, говорят, что если вы что-нибудь сделали, результат обязательно надо протестировать, а после тестирования опять что-нибудь сделать: написать отчет, списать часы, и обязательно в таком порядке, а не наоборот.
Еще в самолётной конторе, я помню, мы с ребятами просто из спортивного интереса боролись, вычищая лишние клики из нашего рабочего процесса. И там на всем жизненном цикле задачи от момента появления до момента закрытия осталось 6 кликов на всю бухгалтерию.
Начинающие менеджеры любят таймшиты: отчеты, сколько часов человек проработал над какой задачей. Они говорят: ребята, вот вам новое поле в таск-трекере, теперь все пишите туда, сколько вы часов туда потратили.
Меня просветил один из моих ребят, очень хороший и мудрый разработчик. В какой-то момент в его недельном отчете я увидел строчку «Писал недельный отчет: два часа». Я понял, нет, за такую цену мне эта информация не нужна.
— Но это же уменьшает количество циферок, которые в итоге получает менеджер?
— На самом деле – не всегда. Я выдумал альтернативный способ их получения. Хороший таск-трекер помнит, в какой момент задача была создана, в какой момент разработчик сказал, что он начал над ней работать, когда он сказал, что можно тестировать, и когда она была закрыта. Конечно, я могу открыть задачу в 9 вечера, сказать «Я завтра её делаю», уйти домой, а завтра сделать за 5 минут и закрыть. В итоге получится, что задачка была активной 13 часов. Но это лишь усложняет задачу, а не делает ее невозможной.
Вот ещё одна мантра: нужно уметь отделять то, что невозможно, от того, что сложно. Мы можем грубо оценить, взять за месяц время активности всех задач, отнормировать его на общее число часов, которое человек был на месте. Мы знаем, что в неделю 40 часов; я ставлю 50 часов, если я вижу, что они реально впахивают. Поделим одно на другое — получим примерное время.
А то, что руками вводят — это на самом деле случайные числа. Я сам представляю, как это делается, поскольку был разработчиком. Ты в конце недели садишься и распихиваешь 54 числа, чтобы в сумме вышло 40.
— А когда тебе, например, захочется, чтобы программисты не брали задачки перед уходом, ты им об этом скомандуешь или попросишь?
— Если мне действительно нужны более точные данные, приду, попрошу, скажу: «Ребятки, смотрите, вместо того, чтобы писать таймшиты, у меня есть супермашинка, которую я своими корявыми манагерскими ручонками налабал, она считает таймшиты сама, помогите ей, пожалуйста».
Власть нужна для тех, кто находится уровнем выше тебя, чтобы он понимал, с кем общается и кому дать по шапке. С ребятами уровнем ниже нужно всё-таки работать именно убеждением.
Об этом написано в книжке «Тойота». В этой компании есть роль главного инженера - человека, ответственного за разработку новой модели автомобиля. Он работает с большим числом команд, которые делают двигатель, подвеску, кузов, внутренности, но у него ни над кем нет прямой власти. Он действует убеждениями за счет своего авторитета. Приходит и говорит: «Надо сделать так-то, потому что …». Если они не согласны, он им объясняет. Когда люди сами поверили, поняли, зачем это нужно, они это делают. Если прийти и приказать, кто-то может сделать — страх и жадность тоже иногда работают — но результат вряд ли бывает долгосрочным. На просьбу помочь ребята редко отказывают. В нашей отрасли откровенных м***ов почти нет.
— С людьми каких профессий тебе приходится больше всего коммуницировать? Ты сам был программистом, знаешь, чем они дышат, а с кем еще?
— У нас есть системные аналитики. Они мало чем отличаются от программистов. Такие же люди, поддаются убеждению или могут сказать, что ты не прав. И твоя задача как начальника — подавить вырывающееся «Сам ты не прав» и послушать, почему они всё-таки так считают. Еще у меня есть тестировщики, приходится работать с системными администраторами, это тоже немножко другая каста — они не пишут код, а ковыряют железки.
— А между ними возникают конфликты — например, классические конфликты программистов, тестировщиков и системных администраторов, которые пытаются разделить ответственность?
— Конфликты возникают, но это больше свойство определенных людей. У нас тестировщики и программисты друг друга любят. С системными администраторами посложнее, но, по крайней мере, они друг друга уважают.
Программист смотрит на маркетолога, думает: «Я тут пишу код, я делаю систему, а это чмо в галстуке не делает ничего, поэтому я буду с ним разговаривать так, как будто он бездельник».
Это лечится профилактической работой. Ты рассказываешь человеку, что вот это чмо в галстуке перелопачивает 54 тысячи сообщений на форуме, смотрит, что реально нужно нашим бизнес-пользователям. Говоришь: а попробуй-ка ты сам, вот тебе полдня, залезь на форум и разберись, что пользователь больше ценит. Как правило, это быстро надоедает программисту, он начинает уважать чужую работу.
В свое время у нас даже были идеи, удачно воплощенные: наших программистов отправлять на ротацию в бизнес-подразделения. Например, ты замечательный, умный программист, полгода-год делал систему для учета платежей, теперь посиди недельку с девочками и повыбивай эти бумажки. Помогает. Один из них вернулся и говорит: «Какой криворукий написал это поле ввода? Оно неудобное».
Какими бывают менеджеры проектов
— Менеджерами проекта сейчас называют всех людей, которые чем-то управляют. Есть ли у тебя в голове внутренняя классификация менеджеров? В частности, сильно ли отличается заказная разработка от продуктовой, инфраструктурной? Какими бывают менеджеры проектов?
— Они бывают умными и глупыми. Я где-то посередине. Это если кратко. А на самом деле специфика проекта, конечно, накладывает отпечаток.
Бывает заказная разработка. Приходит заказчик, просит сделать что-то, что он будет использовать для других, своих заказчиков. Ты не очень понимаешь, кто стоит за спиной у этого человека, не понимаешь бизнес-проблему, которую он пытается решить. Он говорит: напиши мне систему складского учета. На самом деле ему не нужна система складского учета, ему нужно уменьшить размер складов, оптимизировать потоки, чтобы товар попадал с одного склада на другой не за месяц, как сейчас, а за неделю. И на стороне заказчика есть люди, из которых можно вытащить эту бизнес-проблему.
А когда вас попытается нанять гадкий и жадный заказчик, мастерство общения поможет разоблачить его и вовремя отойти в сторону.
В продуктовой разработке чуть иначе. У нас десятки миллионов пользователей, и понять, что нужно им всем или большинству — это отдельное колдунство. Если в заказной разработке мы можем найти человека, который хотя бы понимает проблему, поговорить с ним, получить представление о решении, то с коробочными продуктами такого не бывает. Там уже нужно моделировать пользователей, придумывать целевую аудиторию, на которую мы будем ориентироваться, выдумывать, что же ей нужно, проводить исследования.
Внутренние проекты похожи на заказную разработку. Но бывают еще проекты внедрения: кто-то уже написал здоровенную, хорошую программу, ее нужно всего лишь внедрить в существующую компанию, в существующие правила. Это тоже отдельное искусство, не надо писать много кода, но надо много выдумывать всяких соплей и костылей, чтобы срастить разработку с имеющейся системой существующей компании. Когда ты разрабатываешь что-то с нуля, как в заказной разработке, у тебя больше свободы. А тут – квадратное интегрировать с круглым - бывает сложно.
Бывают еще инфраструктурные проекты, где программировать почти ничего не нужно, но нужно купить много оборудования и сделать, чтобы оно работало. Тоже не так просто.
Один из примеров: мы делали тест-лабораторию для наших исследований и разработок. Нужно тестировать продукт в тысяче различных конфигураций, различные операционные системы, железо, – и чтобы все это делать быстро, надо иметь здоровенную базу тестовых машинок. Машинку с такой операционкой, с сякой, пропатченную, непропатченную, сервис-пак такой, второй, третий и так далее. Комбинаторная сложность ужасная. И, чтобы сделать что-то, эмулирующие одновременно сто тысяч различных конфигураций рабочих станций, надо много думать, много покупать железа, всё это скрещивать. И сделать так, чтобы оно работало. И здесь нужны особые навыки.
Чем отличаются компании между собой? Я уже говорил, что в продуктовой разработке ощутил много суеты. Компании, которые занимаются заказной работой, чуть-чуть поспокойнее, Я думаю, по одной простой причине – есть теория ограничений, которая говорит, что производительность любой цепочки определяется самым медленным звеном – ограничением. И специфика жизни в компании определяется тем, где находится это ограничение, внутри или вне компании.
В заказной разработке, как правило, ограничением является рынок: сколько к тебе заказчиков пришло, столько ты нанимаешь программистов. Крайне редко получается, что человек работает над двумя-тремя проектами.
Как правило, большинство заказной разработки с точки зрения менеджеров – это продажа человеко-часов. Если к тебе пришел клиент и говорит: мне нужно 10 программистов — ты ему даешь 10 программистов, ты не можешь одного и того же двум заказчикам продать.
В продуктовой разработке ограничением является твоя собственная компания. Заказная разработка – идея поступает от заказчиков, от внешней компании. Сколько их пришло, столько у тебя и есть. А в продуктовой разработке – особенно если это продукт типа нашего, или Acronis, Paragon для миллионов конечных пользователей – нет пользователя, который приходит и дает тебе идею. Есть специальный отдел маркетинга или еще кто-то, кто выдумывает эти идеи. А мы знаем, что человеческий мозг способен генерировать очень и очень много идей. Соответственно, мы в продуктовых компаниях сразу имеем много идей и пожеланий, которые нужно вложить в наш продукт, в несколько десятков раз больше, чем физически способны сделать.
Появляется давление. Каждый считает, что его фича самая важная: у него свой контекст, он прорабатывал эту фичу, месяц выдумывал, ковырялся по форумам, он ее любит как родную. А про ту фичу, которую другой человек месяц прорабатывал, скажет – ну, фигня какая, подумаешь, «вирусы лечить». Вот у меня делает бэкапы диска, вот это да – посмотрите, какой рынок этих систем, какие бывают диски, какие бывают сложности. А там-то – вирусы, блин, да кому это нужно!
Поэтому, имея ограничением саму компанию, мы имеем давление. Кто-то сможет с этим жить, кто-то не сможет.
У нас бывает… Точнее, в исследовании и разработке в свое время было — сейчас, я думаю, они это уже победили — но было нормальным, когда один человек работал над тремя проектами одновременно. Разрыв мозга. Понятное дело, что он не делает ничего быстрее. На самом деле, вообще ничего не происходит. Но иллюзия «что-то движется, ты родил идею, и всё зашевелилось» заставляет думать, что это будет сделано. А поскольку давление есть везде, ты об идее быстро забываешь и выдумываешь новую.
— Может ли менеджер часто менять специализации и виды проектов?
— На этот счёт бытует два мнения. Одно — что хорошему менеджеру пофиг, чем управлять, второе — что менеджер должен все-таки специализироваться в одной области. Я постоянно прыгаю между этими двумя убеждениями, то одно мне кажется справедливым, то другое.
Сейчас думаю, что всё-таки менеджер должен понимать специфику того, чем он руководит. И менеджер, который всегда управлял инфраструктурными проектами, не сможет первое время эффективно и хорошо управлять разработкой. Тот, кто обеспечивал внедрение, не сможет сделать нормальную инфраструктуру. Понимание специфики помогает. Но опять же: «первое время» – ключевое слово. Потом, когда-то, если человек способен обучаться, он набьёт шишки, получит дополнительный опыт, станет лучше.
Шишки новичков
— Ты вырос из программиста в менеджера. А есть другие варианты развития?
— У нас один менеджер вырос из тестировщиков. Есть менеджеры, которые получаются из аналитиков. Есть менеджеры, которые получаются из плохих программистов — это клиника, но такое, к сожалению, попадается.
— Но у всех у них есть IT-бэкграунд?
— У подавляющего большинства. Как минимум хоть какой-то программистский опыт, сейчас даже чаще тестеры попадаются, не знаю, почему. Наверное, потому что они идут в тестеры, не умея программировать, а потом… Хрен его знает. Начиная этот путь, надо ответить на вопрос «зачем?». Если первый ответ – «зарплата больше», лучше не начинать.
— Потому что она не больше? Или потому что не получится?
— Скорее всего, не получится. Зарплата больше не в разы. Нет. У нас есть программисты, у которых зарплата сильно больше менеджерской. Даже тестировщики такие есть. Сейчас уже это выровнялось. Менеджер проектов — такой же персонаж, как и большинство остальных, как и программисты, и тестировщики, и аналитики. Просто у него чуть-чуть другая работа. Ну хорошо, сильно другая работа! Ему не надо писать код, ему надо писать в Аутлуке. Одни пишут в Вижуал Студио, другие – в Аутлуке. На первый взгляд, примерно одним и тем же занимаются.
— Но программистам приходится работать с компьютером, который всегда правильно реагирует на твои команды, а менеджерам – с людьми.
— Которые не всегда правильно реагируют. Компьютер тоже, кстати, подкидывает сюрпризы.
— Но люди, наверное, все-таки больше.
— Ну да. Компьютер не может уйти в декрет – факт.
— Людей надо любить, наверное.
— Железо тоже! Кто-то у нас из админов на вопль: «Что там у вас опять не работает?!» сказал: «Сервер! Вы не думайте, что он железный, у него есть душа. Лёг отдохнуть». Вот так они любят свои железки. Мы тоже любим и админов, и их железки.
По кодотерапии помню, что когда ты работаешь программистом, очень тяжело перестраивать мозг на решение менеджерских задач. Происходит какой-то щелчок. Чувствуется, что это две разные области.
Надо понять, нужно это человеку или нет. Какой шарм в этой работе?
Она – про другое. Здесь ты уже программируешь не компьютер, а фактически программируешь людей, помогаешь им достигать успеха. Хорошо, когда ты берешь трех не самых умных программистов и с их помощью делаешь то, что 5 очень умных не способны сделать. Это — хороший тимлид. Хороший менеджер — это, наверное, человек, который их всех еще и заставит приносить компании прибыль.
— Есть ли самые типичные заблуждения новичков?
— Новички-студенты приходят на позиции разработчиков. Первое их разочарование: кода надо писать не так уж много, а надо читать книжки, документацию, чтобы разобраться в том, что мы пытаемся сделать. Надо планировать свою работу, помогать тестировщикам. Получается не просто восемь часов непрерывного кодинга. Кодинга – часа четыре, а то и меньше.
А на позицию PM’ов новички не приходят, честно говоря, я и не взял бы их. Им надо сначала понять, что это за индустрия.
— Есть ли черты характера, которые должны быть у менеджера, без которых он не сможет быть менеджером, провалит проект?
— Нужно уметь разговаривать с любыми людьми. Особенно с теми, кто тебя умнее. Это очень тяжело – признавать, что ты глупее собеседника. Это надо делать.
— А можно быстро понять, что перед тобой стоит человек, который не может быть хорошим менеджером? И как ему это понять? Какие вопросы он должен задать себе?
— Если он программист и приходит на позицию менеджера, говорит: «я хочу быть менеджером», то, думаю, сработает вопрос: «согласен ли ты быть менеджером, но с зарплатой на треть меньше?». Если человек готов, то, наверное, он хочет не денег, а чего-то другого. В менеджеры очень многие идут исключительно из-за зарплаты и этим портят карму.
— А у тебя есть какие-нибудь любимые вопросы для интервью PM'ов?
— «Какую книжку по управлению ты прочитал за последний месяц?». Если в ответ слышу «PMBOK» — это, скорее всего, говорит о том, что человек не читает ничего в принципе. Этот вопрос «какую книжку ты прочитал за последний месяц?» – универсальный, ко всем подходит в нашей индустрии.
— Какие книги ты порекомендуешь начинающим менеджерам?
Вот что я посоветовал бы начинающему себе, чтобы быстрее прокачать мозги: обязательно Друкера и Эмерсона, серию книжек Голдрата «Цель-1», «Цель-2», «Цель-3», «Новая цель» — хотя первой может быть достаточно. Потом Уильям Детмер «Теория ограничений Голдрата». Может быть, у меня сейчас просто акценты смещены, но теория ограничений действительно понравилась.
По бережливому производству: отличные книжки Джефри Лайкера «Дао Toyota» и «Практика Дао Toyota». Я рассказывал об использовании этих принципов в IT на мероприятии «Greenfield Project».
Про это же — Мэри Поппендик с ее замечательной книжкой.
Финальный блиц
— В какой момент ты чувствуешь радость, драйв, адреналин, подъём?
— Поставлена очередная галочка напротив завершенного проекта. Сделано. Чик – галочка.
— А что, наоборот, приносит разочарование? Какой момент самый противный?
— Когда понимаешь, что люди не хотят думать. Думать – это очень сложно. Многие люди, вне зависимости от занимаемой должности и выполняемой работы, иногда не хотят думать.
— У тебя есть миссия? Что-то новое, что ты приносишь в мир.
— Сейчас я несу в мир знание, хочу этим знанием делиться. Лучшее тому доказательство — мой Slideshare.