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

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

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

---

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

«Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным». (С) Сенека, Луций Анней

Предисловие

Как-то один из топов уважаемой компании, которая занимается продуктовой разработкой ПО, пригласил меня, как эксперта, чтобы я оценил качество нового продукта. Я внимательно просмотрел и прослушал презентацию. Видно было, что коллеги очень старались и работали по 10-12 часов, чтобы продукт выглядел на высшем уровне. После чего меня спросили: «хороший получился продукт или нет?» Я поблагодарил за представленную презентацию, но попросил ответить на свой последний вопрос: «А какие процессы, и с какой целью вы собираетесь автоматизировать с помощью этого инструмента?» Вопрос почему-то вызвал замешательство у докладчиков. После небольшой паузы, топ, который, видимо, был идеологом нового продукта, ответил: «Был бы инструмент хороший, а какие процессы с его помощь автоматизировать мы найдем!» Мне пришлось сказать, что оценить продукт я не смогу. Не зная бизнес-целей, невозможно понять степень их достижения.

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

Для иллюстрации используем проект «Экспедиция за сокровищами Флинта»

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

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

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

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

Как и обещал в «песочничном» посте, рассказываю сейчас о своей актуальной системе записей в WorkFlowy (WF). Ни в коем случае не претендую на то, что она лучшая на свете и сразу всем подойдет. Просто рассказываю.

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

Этот пост, в том числе, призыв поделиться своими историями успеха.

Эта статья — how to для саппорта по общению с клиентами, как общаться с клиентами, с которыми общаться невозможно: враждебно настроенными, озлобленными, мнительными — тех, что мы привыкли называть неадекватными.

Product manager – позиция неоднозначная. На постсоветском пространстве еще не сложилось полноценной культуры управления продуктом, хотя продуктовых компаний уже в общем-то немало. «Продактами» становятся бывшие бизнес-аналитики, проектные менеджеры, маркетологи и другие специалисты, каждый из которых по-своему подходит к своим новым задачам. Я хотел бы поделиться несколькими тезисами о работе с новыми фичами продукта, которые кажутся важными с моей колокольни.


Это тоже в своем роде управление продуктами, но речь пойдет о другом.

Disclaimer:

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

«Вы продолжаете использовать это слово. Я думаю, оно означает не то, что вы думаете оно означает»
— Inigo Montoya

Работая full-time на управленческих должностях последние несколько лет, я все больше убеждаюсь, что широко распространены заблуждения о роли менеджера и о менеджменте как профессии, и эти заблуждения портят жизнь и нервы многим людям. Тема менеджмента полна слухов и мифов, здесь я расскажу только о наиболее ярких примерах.

Миф №1. Менеждмент — это то, что делают менеджеры

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

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

Привет, хабраобщество!
Давно не писал материалов, всё больше читал чужие. Но вот, выдалась свободная минутка (пока с трёх iMac'ов сливаются свадебные фото c дисков ввиду отсутствия у моего бука привода :) и я решил выложить материал про наш рабочий процесс. Мы — молодая компания Fruitware из солнечной Молдовы, а я сам совмещаю должности коммерческого и исполнительного директора, хотя наиболее опытен я, как ни странно, в веб-программировании.

Наша компания прошла довольно значительный путь длинной в полтора года от «гаражной» студии из 5ти человек до серьёзной организации из 40.
Я скажу вам честно — увеличиться в 8 раз — это не самый безболезненный процесс и нас не раз лихорадило. Но, учась больше на своих ошибках и немного на чужих, мы построили свой порядок работы, начиная с технического оснащения и до управления проектом.

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

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

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

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

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

Небольшой обзор адаптации инноваций на примере «Epiphan Distance Doc 2» для участия в госзакупках.

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

Крутой стартапер

Продукт не важен, важно что он теперь крутой стартапер. Вы там, мол, делайте и работайте, a я пощеголяю. Ходит на тусовки, пишет в блоге статейки, снимает видео про стартаперство. Как быть крутым стартапером? Как выбрать название фирмы? Спросите у него! Через пару месяцев приходит разочарование: вроде бы он крутой стартапер, а дело не движется. Но ничего. Он найдёт в тусовке знакомых, у которых тоже не движется и успокоится.

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

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

Все это в конечном итоге подвигло нас на сегментацию наших текущих клиентов. Мы проанализировали нашу текущую клиентскую базу и классифицировали всех клиентов на 4 больших группы и вкратце описали тактику работы с каждым сегментом.

В 2009 году я рассказывал, как мы строим наш маленький семейный бизнес с оборотом 1500 долларов в месяц. Прошло четыре года. Бизнес вырос до оборота 500 000 долларов в год, и мы его потеряли. Самое время рассказать о допущенных ошибках.

Что же произошло?

Публикация на хабре позволила нам познакомиться с разными людьми, наш бизнес многим понравился. Так в 2010 году мы продали 50% компании частным инвесторам. После успешной трехлетней совместной жизни в сентябре 2013 года наши партнеры отжали бизнес. Мы остались ни с чем.

Как говорил Франклин, “Опыт — это чудесное умение распознавать ошибку, которую ты допускаешь снова”. Возможно, для кого-то все, написанное ниже, знакомо и понятно. Для нас это было впервые и, оглядываясь назад, я вижу множество ошибок, которые привели к такой ситуации. Буду рад ими поделиться с вами.

Думаю, данная статья будет актуальна для многих IT отечественных НЕсофтверных компаний большого и среднего размера с «карманным» IT, не ориентированных на выпуск «коробочных» продуктов, более всего описанные ниже ситуации характерны для компаний, где IT является «приложением» к основному бизнесу. Статья ни в коем случае не претендует на истину в последней инстанции и не дает никаких «особенных» рекомендаций, кому что нужно делать, а лишь иллюстрирует возможные варианты развития возможных участников в ситуации «как сделать так, чтобы не загубить систему» с уклоном на составление ТЗ и на отношения в коллективе. Для многих ситуация может быть более чем очевидна, а некоторым откроет глаза, так что, возможно, кому-то и будет полезна, а также принесет в жизнь немного юмора.

Рассмотрим обычный пример из жизни обычных программистов в такой компании: разрабатывается большая система X, в которой много чего сложного и интересного (а иногда — не очень интересного) — и бизнес работает вполне успешно, и программисты есть, и менеджеры/аналитики — как связующее звено между бизнесом и программистами. Все вроде бы ровно, отлажено, работает. И кода много, и багов. И актуальной документации зачастую днем с огнем не сыщешь… В общем, все «как у всех». Жить можно.

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

Им удобно пользоваться, есть совместный доступ, собственно, почему нет?

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

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

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

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

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

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

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

В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.

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

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

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