Управление проектами *

В продолжении перевода первой статьи Стивена Синофски о продуктовой разработке — перевод его второй статьи, про важность обмена опытом в команде, разрабатывающей продукт.

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

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

Зачем делать отчеты о поездках?

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

Отчет, это всего-то — набор слов и материалов, это далеко не список дальнейших действий, поскольку их можно сформулировать лишь, собрав данные с разных точек зрения и обдумав все последствия. На самом деле, ошибочно при разработке продукта тотчас кидаться воплощать все соображения, которые кто-то «привез» из одной из командировок или же чью-либо личную точку зрения (и не важно, кто из команды написал этот отчет). Это всего лишь рассказ, и чтобы превратить его в конкретные шаги — смену плана или изменение состава возможностей — нужна отдельная работа.

Подходы

Не существует «правильного» способа составления отчета. Чаще всего его формат, структура и детали должны определяться тем, что это за событие: выстраиваете ли вы структуру по типам технологий или поставщику, по потребителям или темам потребителей, по сессиям конференции, по техническим подсистемам или как-то еще?

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

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

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

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

К этой статье меня подтолкнул большой перекос, который я вижу в массовом сознании и сознании профессионального сообщества менеджеров IT компаний. Увы, сайтов про управление проектами море, а про управление продуктами — кот наплакал.

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

В книгах по управлению проектами (особенно для новичков) авторы очень любят начинать с тезиса о том, что мир состоит из проектов, проекты везде. Готовите еду — проект, лечитесь у доктора — проект, ковыряетесь в носу или занимаетесь любовью, даже отпуск — всё проекты.

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

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

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

1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?

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

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

2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)

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

Менеджеру: ничто так не демотивирует, как обвинение в некомпетентности и лжи. Постарайтесь давать точное ТЗ и бить задачу на простые кусочки, в чем программист с удовольствием поможет (если хорошо попросить). Тогда можно будет более точно управлять сроками.

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

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

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

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

Но идем дальше.

Продолжение статьи Пола Грема о поиске идеи для стартапа. Первая и вторая части тут. Без лишних слов продолжаем:

Университет

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

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

Сознание

Но как определить, есть ли путь «наружу» у идеи? Как понять, является ли это зачатком большой компании или всего лишь продуктом, обреченным на узкую нишу? Часто это не возможно сделать. Фаундеры AirBnb не осознавали в начале, на рынок какого масштаба они покусились. Изначально у них была более узкая идея. Они собирались позволить владельцам сдавать свое пространство во время выставок, конференций. Они не предвидели экспансию этой идеи; она сама себя навязывала постепенно. Все что они знали в начале, что на крючке какая-то рыба. Возможно, это столько же, сколько знали изначально Билл Гейтс и Марк Цукерберг.

Недавно вышла статья Пола Грэма о поиске идеи для стартапа. Грем — сам по себе культовая личность Кремниевой долины и уже только поэтому достоин внимания. Но на мой взгляд, эта статья одна из лучших в своем роде. Да, о Customer Development и Lean Startup сейчас не пишет разве что ленивый, но она отличается глубокой внутренней философией Грема и обобщает его богатый опыт в качестве основателя YCombinator, общающегося с тысячами стартаперов в год.
Статья очень длинная, поэтому я взял на себя смелость разбить ее на 5 частей, дабы никого не утомить. Поехали:

Лучший способ найти идею для стартапа — не думать о ней. Найдите проблему, и лучше — если она есть у вас самого.

В ходе DLD Conference в Мюнхене венчурный капиталист Бен Хоровиц рассказал, почему он и его фирма Andreessen Horowitz инвестирует в определённую компанию и её основателей, пишет TechCrunch. В прошлом году Andreessen Horowitz нашла 2355 компаний, которые потенциально были достойны инвестирования. Однако в итоге фирма закрыла только 24 сделки (не считая начальных инвестиций). Дошедшие до финала компании, как утверждает Хоровиц, были основаны «теми, кто бросил колледж и имеет безумные идеи для крошечных рынков без монетизации».

Говоря о сумасшедших идеях, Хоровиц отметил, что в 1975 году программное обеспечение не было тем, во что кто-то стал бы инвестировать. Рынок был слишком мал, и большинство людей не думали, что что-то вроде Altair Basic является жизнеспособным продуктом. Однако Microsoft считал иначе. В 1998 году веб-поиск считался плохой идеей для инвестиций, поскольку большинство уже существовавших поисковых компаний не умели на этом зарабатывать. Однако Google придумал как.

От переводчика: Основатель imgix, бывший разработчик Youtube Chris Zacharias рассуждает о прохождении курсов YCombinator и опыте получения инвестиций. Недавно я также публиковал перевод второй статьи из блога автора — Кое-что о весе страницы.

Когда летом 2011 года я проходил курсы YCombinator, мне казалось, что я единственный человек в группе, который ничего не знает об инвестировании. Я отчётливо помню, как Джессика Ливингстон сообщила о $150 тыс., которые мы можем получить от SV Angel и Start Fund. Когда она рассказала об условиях инвестирования, аудитория наполнилась овациями. Я же сидел и нервно гуглил, пытаясь понять, что только что было сказано и должен ли я вообще здесь находиться.

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

Я — фрилансер.

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

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

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

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

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

Если вы нашли себя — поделитесь в комментариях!

Добрый день, хаброобщество.

Мой пост — отклик на многочисленные публикации в стиле «Менеджер vs технический специалист. Блуждание души».

Я работник одела управления проектами ИТ одного из министерств. В мои обязанности входит две задачи: администрирование продукта нового проекта и, собственно, пока продукт в стадии разработки, ведение всех вопросов, лежащих в плоскости проекта и моей компетенции.

В отделе нас трое: начальник и двое специалистов, к коим я и отношусь. Три серьёзных проекта плюс несколько небольших. Это моя стартовая точка к росту в ПМ. Да-да, я очень хочу стать менеджером. Дальше небольшая история о том, как я осознал, чего хочу от работы.

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

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

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

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

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

Удивительно, что человек проработал 10 лет менеджером в ИТ, а у него нет инструкций и документации, что же должен делать менеджер в течении дня. Так может учебник «Основы менеджмента» хотя бы стоило прочитать. А вообще-то менеджмент — это такая научная специальность отдельная… Тысячи научных специалистов трудятся в ней, какие-то теории управления придумывают, книги издают, исследования проводят, те же agile-методы (scrum и другие) развивают. Может там следует инструкции поискать? Ах да, там же одна «водичка» написана, а у нас тут реальные проекты, да еще и работники какие-то неправильные, ни под одну теорию менеджмента не вписываются.

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

1. Ещё одна ступенька, в жизни, карьере, зарплате.

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

Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.

Прежде всего хочу заметить, что доктор биологических наук Сергей Савельев в книге «Изменчивость и гениальность» говорит, что мозг каждого человека под что-то создан. Кто-то имеет мозг программиста, кто-то управленца, кто-то обе сферы может осилить. Но обычно талант вынуждает человека делать то, что ему нравится. А к чему он не создан, его радовать не будет, и в это все дело.

Таким образом, к примеру, есть мозг художника, и он не будет математиком. А математик часто не может писать гениальные стихи, и так далее. Бывают гении, типа Леонардо да Винчи, но это исключение.

Весь вопрос в том, чтобы освоить азы профессии, и если она нравится — ей и нужно заниматься. Если нет — пробовать себя в чем-то другом.

Поэтому универсальных советов нет, каждому нужно искать свое дело.

Это было предисловие, а теперь про плюшки работы управленцем.

Итак, что в управлении проектами круто.

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