Тренинги и семинары для бизнеса
телефон в Иркутске: +7 (3952) 50-03-04

Об управлении IT — проектами

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

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

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

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

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

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

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

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

Я начал ему говорить: чувак, ты делаешь не так, давай мы сейчас эту задачу распилим, сделаем по-моему, тогда мы её поставим раньше и успеем сделать ещё что-нибудь. В общем, начал его учить жизни.

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

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

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

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

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

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

Короче говоря, я трачу его время, а значит — плачу деньги.

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

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

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

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

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

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

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

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

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

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

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

Там я сразу столкнулся с жесткими реалиями Business Application Development. Один из проектов был для крупной западной компании, мы автоматизировали систему складского учета.

Сейчас я понимаю, что этот проект по большому счету стал моим позором.

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

О нас

Байкальский Центр Тренинга работает 16 лет в области организации и проведения бизнес-семинаров и тренингов, кадрового консалтинга. Подробнее

Подписка на новости

Подписаться