Заметки на полях

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

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

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

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

Иногда перед менеджером стоит дилемма, что выбрать – сроки или качество. Что лучше – запустить вовремя или отложить релиз, но подойти к этому тщательнее? Каждая ситуация, конечно, индивидуальна, но приоритет лучше отдавать срокам. Как правило, только релиз обнажает истинные проблемы продукта и в итоге позволяет достичь нужного уровня качества.

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

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

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

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

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

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

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

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

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

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

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

Если вы хотите организовать какое-либо исследование, например, a/b тест, важно выполнить все условия репрезентативного исследования (правильно выделить исследуемую область, исключить влияние других факторов, обеспечить релевантную выборку). В большинстве случаев это бывает либо очень сложно, либо очень трудоемко и не стоит того. Поэтому, подумайте – готовы ли к тестам, или проще довериться интуиции.

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

Иногда запуск проекта требует определенной решительности со стороны Заказчика. Остерегаясь неудачи, или несоответствия результата взятым ранее на себя обязательствам, Заказчик может начать откладывать релиз, добавляя новые функции, без которых, как ему кажется «запускаться нельзя». Это опасная для проекта ситуация, когда менеджеру надо помочь Заказчику, а возможно и разделить с ним ответственность.

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

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

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

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

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

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

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

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

Чем больше людей, тем больше потребуется времени. Как бы это странно не звучало, но при организации работы команды из нескольких разработчиков, все больше и больше трудозатрат уходит на коммуникации между участниками, на координацию. При добавлении каждого дополнительного разработчика, производительность труда (выработка на человека) становится меньше. Наиболее эффективны команды из 2-3 разработчиков, а управлять командой из 10 и более программистов крайне тяжело.

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

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

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

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

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

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

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

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

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

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

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

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

Если кто-то говорит несколько раз, что задача готова на 90%, скорее всего у вас проблемы и она не будет готова никогда. Оценка в 90% в большинстве случаев возникает тогда, когда исполнитель сам не понимает, почему она до сих пор не выполнена. Значит, изначальная постановка слишком отличается от вновь вскрывшихся обстоятельств.

Любой Заказчик мечтает о том, чтобы выдать задание, а потом только получить готовый результат. Любой разработчик спит и видит, чтобы получить задание, сделать, и сдать. Желания совпадают, но в реальности так никогда не получается. Одному не нравится полученный результат, другой пеняет на задание. Это как в браке - счастлив не тот кто не ссорится, а тот кто умеет помириться.

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

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

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

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

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

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

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

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

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

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

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

Никто не любит тестировать. Поэтому нанимают тестеров.

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

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

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

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

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

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

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

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

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

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

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

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

Нет однозначного совета, как отделить хорошего «специалиста» от «плохого». Иногда какой-то программист может быть плох в линейных задачах, но повышает общий предел некомпетентности команды, и наоборот. Лучший способ отказаться от абсолютных оценок, и дать команде решить самой – кто лидер, а кто отстающий. Когда у вас 3-4 и более разработчиков, быстро становится очевидно, кто «слабое звено».

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

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

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

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

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

Никто не любит ковыряться в чужих ошибках и коде …

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

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

Слабый разработчик отнимает времени больше чем производит – команда из 2-х сильных сделает больше, чем команда из 2-х сильных и 3-х слабых. Добавьте им еще парочку учеников и они не сделают ничего. Зато если на 2-х сильных дать одного ученика, через некоторое время он тоже подтянется.

Очень легко отличить хорошего менеджера от плохого. У хорошего менеджера нет цейтнота, он все успевает и, как правило, у него еще остается немного свободного времени. А проект идет.

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

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

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

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

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

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

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

Пока сайт или функция не внедрены, они не сделаны.

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

Проект никогда не завершится, если отклонять все новые требования, но если все требования принимать, то он не завершится тем более. Задача менеджера - найти эту «золотую середину», постоянно соотнося задачи с MVP (Minimum Viable Product). Лучше всего создать некое «сопротивление на вход», некоторый набор сопротивлений новому требованию. Если требование «прошло», то можно делать, а если нет, то и не надо.

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

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

Самых лучших специалистов привлекают только самые интересные задачи.

Если между релизами (итерациями) сменить менеджера можно относительно безболезненно, то не очень здорово менять менеджера по ходу работы над итерацией. Однако, если это придется все-таки сделать, проект меньше пострадает, если одна большая (мажорная) итерация будет разбита на множество маленьких (минорных).

Качество проекта – это конкретные люди, которые его делают. Поэтому очень важно развивать и обучать сотрудников. Но никто не может эффективно работать в бардаке. Поэтому не менее важно параллельно выстраивать бизнес-процессы.

У требовательного (в хорошем смысле этого слова) заказчика проект идет полным ходом. У слишком мягкого и лояльного часто есть большие проблемы со сроками и качеством проекта.

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

Если менеджер продукта (человек, который решает, что делать) и менеджер проекта (ответственный за то, как) разные люди, то такой тандем может чаще находить точку эффективности между сделать побольше, и сделать получше.

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

Эффективный менеджер – это сотрудник, который решает те задачи, которые надо решать в данный конкретный момент, а не те, которые хочется или интересно.

Самые простые методы управления проектами: митинги, планерки, встречи с Заказчиком - остаются самыми эффективными! Чем сложнее проект, тем более необходимы эти инструменты.

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

Если хотите сильную команду, то жестко убирайте слабаков

При общении с Заказчиком хороший менеджер будет отстаивать позицию программистов. При общении с программистами будет на стороне Заказчика. Роль менеджера искать вместе со всеми участниками проекта компромисс.

Управление любым проектом состоит из огромного множества мелких действий – сделать звонок, поставить задачу, уточнить определенный момент, поправить фразу в ТЗ и т. д. К каждому такому шагу надо относиться уважительно – не откладывать и стараться выполнить как можно лучше. Часто состоявшиеся менеджеры так увлекаются стратегическим планированием, что совсем забывают про эти необходимые шаги, и их результаты хуже, чем у начинающих.

Хороший менеджер интернет-проекта – это человек, увлеченный вебом, а не просто абстрактным управлением.

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

Есть только один способ правильно расставить приоритеты – это противопоставить задачи, ответив на вопрос «либо-либо». Проще всего это сделать через «нормирование», когда у вас есть определенное количество часов специалистов и временная оценка задач. Тогда вы выбираете, что «влезет», а что нет – это и будут настоящие приоритеты.

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

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

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

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

Все понимают, как важно, чтобы продуктом было удобно пользоваться. Но почему-то мало у кого получается это реализовать. Хороший специалист по юзабилити – это тот, кто умеет посмотреть на продукт глазами нового пользователя. Менеджер должен развивать в себе эту экспертизу. Хорошо работает такой подход: представить себя в роли знакомого человека (похожего на ЦА), придумать его, вжиться в эту роль и пользоваться продуктом от его имени.

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

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

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

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

В идеале успешный проект – это и довольный Заказчик, и качественно выполненный продукт, которым можно гордиться, и рентабельный проект. Реально ли достичь все эти цели одновременно? Конечно. Только это будет очень дорогой проект.

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

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

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

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

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

Если привлекаемый на сайт покупатель стоит очень дорого (а в интернете это рано или поздно обязательно произойдет), менеджер должен думать прежде всего о всем жизненном цикле покупателя, стараясь заработать не на первой покупке, а на том, что будет после этой покупки.

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

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

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

Какие факторы чаще всего недооценивают начинающие стартаперы? Будущие трудозатраты, финансовые вложения, длительность периода раскрутки или еще что-то? Чаще всего – все. Поэтому успешнее оказываются не те, кто заранее все правильно спланировал, а те, кто быстро перестроились, переделали, пересчитали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда мы очевидно понимаем, что наш специалист или тимлид откровенно слаб и мешает проекту развиваться. В большинстве случаев, решение только одно — заменять. Однако, важно не оказаться в ситуации, когда такая замена становится невозможной. Чтобы этого не допустить, стоит всегда иметь в команде не менее 3-х специалистов, а размер итерации не более 4-х месяцев.

Можно ли как-то бороться с тем, что менеджеру наскучил проект? К сожалению, нельзя. И не нужно. И проекту, и менеджеру пойдет на пользу пауза в их отношениях. Если такое расставание пройдет системно, с плавным отходом менеджера от дел, в этом нет никаких рисков. Главное не допускать внезапных расставаний.

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

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

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

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

Нет лучшей аналогии для описания роли менеджера проекта, чем дирижер в оркестре. Он помогает профессионалам синхронизироваться, выступать единой командой. Мешает ли менеджер реализоваться 5-ой скрипке, как самостоятельной творческой единице? Конечно.

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

Каждый новый способ продвижения (не только в интернете) сначала никому не понятен и не интересен. Однако, всегда есть начинающие бизнесмены, студенты и стартаперы, неспособные оплачивать классическую рекламу и готовые экспериментировать со всем подряд. Однажды, им удается найти как этот новый инструмент применять, и с этого момента этот канал начинает дорожать и, рано или поздно, превращается в привычный и недоступный. Например, сейчас, в 2014 г. SMM еще в поисках, а SEO уже закончилось.

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

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

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

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

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

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

Как хорошему менеджеру работать с по-настоящему неконструктивным Заказчиком (например, слишком эмоциональным, безответственным, конфликтным)? Никак. Опытный менеджер сделает все, чтобы максимально быстро и безболезненно прекратить сотрудничество с таким Заказчиком. Невозможно эффективно управлять проектом без поддержки Заказчика. А значит, либо с Заказчиком можно конструктивно сотрудничать, либо проект будет провален.

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

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

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

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

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

Что важнее — получить больше лидов или качественнее их обработать? Все просто. Пока вы можете себе это позволить, то есть покрывать стоимость привлекаемого лида — надо фокусироваться на лидогенерации. Лидменеджмент и лучший % конверсии из лида в покупателя просто поднимает границу допустимой стоимости лида и позволяет вам снова заняться лидогенерацией.

Всякое нормирование нагрузки на разработчиков, условные человеко-часы, рабочее время всегда условно. Сотрудники уходят в отпуска или болеют, всегда что-то оказывается несогласованным, появляются незапланированные простои. У менеджера нет задачи привести систему к идеальным лабораторным условиям. Цель всякого планирования компенсировать неожиданные потери, такими же незапланированными «приобретениями».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработчикам, веб-студиям, агентствам очень тяжело оценить эффективность своих маркетинговых усилий. Что лучше? Написать кейс или выступить на конференции? Увеличить затраты на рекламу или рассчитывать только на рекомендации? Ответ на этот вопрос найти тяжело, и скорее всего, и не нужно. Это рынок профессиональных услуг. Хорошее позиционирование и равномерное вложение во все каналы и инструменты дает максимальный эффект.

Лучшие из лучших мотивируются задачами, которые перед ними ставят. Начинающие возможностью обучаться и развиваться. А как быть с условным «середняком»? Никак. Середняк всегда работает так, как работают вокруг.

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

Когда мы решили каждый день, в течение почти года писать полезные заметки для менеджера проекта, мы хотели делать это качественно, с душой, вкладывая весь свой текущий опыт и знания. Именно поэтому, мы отнеслись к этому как к проекту и решили написать ровно 200 заметок. Это 201 наша заметка.