Александр, мотивация деньгами практически не работает. Особенно среди программистов. По-моему, уже считается азбучной истиной, что деньги — это гигиенический фактор. Без них очень плохо, но они не заставляют работать лучше. Вернее, они могут мотивировать, но очень небольшую долю людей. Вообще, каждого мотивирует что-то своё. Кого-то деньги, кого-то стабильность, кого-то хороший коллектив. Вот презентация в тему (правда, без доклада немного хаотична).
Кстати, насчёт обмана: знаете, что на «нематериальную» мотивацию порой уходит в десятки раз больше времени и денег, чем на «материальную»? И кто кого обманывает в результате ;)?
Соревнование между командами, выполняющими одни и те же задачи, которым не приходится участвовать в общем проекте — это здоровое проявление конкуренции. Взять, например, сюжет Deadline Тома Демарко. Это как раз развитие темы. Но внутри команды конкуренция губительна.
Вот вы пишите, что программисты — они не за что не отвечают и обычно тупо пишут что сказали. Я с этим спорить не буду. Возможно в отдельных компаниях так принято. Может быть даже их большинство.
Я не о том сказать хотел: вопрос не в том, что «работает только одно полушарие из двух» а в том, что в проекте у программиста и маркетолога-аналитика-продакта-заказчика (зовите как хотите) принципиально разные ценности. Сам долгое время работал программистом, кроме того, с несколькими десятками девелоперов взаимодействовал в роле ПМа, аналитика, продакта и заказчика. Ага, на вполне крупных промышленных проектах.
И наблюдения чисто статистически показывают: основная ценность для программиста — чёткая, структурированная система без костылей, красивый код, правильная архитектура. Я встречал очень мало программистов, которые готовы принести красивую архитектуру в жертву удобству пользователя, если их прямо не заставить так делать. И это нормально и правильно. Если программист не ценит нормальную архитектуру и красивый код, грош ему цена.
Но есть и другая категория — ПМы, продакты, заказчики, вышедшие из тех же программистов, и по старой памяти ценящие код, архитектуру и внутреннюю строгость системы выше удобства пользователя и общей юзабельности системы. Вот это уже сильно плохо, и это лечить надо. Как раз как тот «заказчик», который по вашей версии зафичекатил сохранение данных в гос. услугах (впрочем, что-то у меня большие сомнения, что такой вопрос вообще поднимался).
В общем, смело можете менять слова «левополушарное мышление» на «особенности логического мышления программиста, связанные с его профессиональной деятельностью», Может быть, так будет проще понять смысл статьи, не отвлекаясь на заезженные штампы
Я уверен, что помимо написания кода программисты ещё иногда живут :). Они используют сервисы навигации, ищут информацию в интернете, играют в боулинг и лазертаг, ходят на дни рождения к друзьям, дарят подарки любимой девушке, копают тёщин огород :)
Я к тому, что не обязательно делать продукты для разработчиков, чтобы ими пользоваться. Я слышал замечательную историю о ребятах, которые для написания софта о логистике купили фуру и полгода колесили по стране.
Про встроенную штуку — вопрос немного более сложный. Кто её пользователи? Вероятно те, кто её встраивают. Сможете ли вы её встроить на самом деле? Сможете ли вы попасть на атомную станцию, чтобы протестировать софт для её оптимизации? Всё зависит от вас. И не акт, что получится. В этом случае придётся просто долго наблюдать их работу и представлять себя на их месте.
Я думаю, это характерно для любой профессиональной деятельности. На начальных этапах любой деятельности всегда нужен ментор, учитель, сенсей (выберите подходящее)
Некоторое время назад писал здесь текст о трёх уровнях развития программиста.
Данная статья великолепно иллюстрирует переход от второй ступени программиста — «сделаем всё и везде идеально и накрутим сложной архитектуры» (у меня есть знакомый, который называет таких товарищей «архирастами») — к третьей, которые понимают, что микроскоп — это микроскоп, а молоток — это молоток, и использовать микроскоп для того, чтобы забить гвоздь, только потому, что это более совершенный инструмент, смысла нет.
«Даже если вас съели, у вас ещё остаётся два выхода» :)
Я очень хорошо представляю такую ситуацию, так как не раз с ней сталкивался. Я бы не стал продолжать вкладывать ресурсы в брутфорс того, что не приносит никакой пользы. Обычно мы в таких случаях начинаем массово пробовать большое количество различных вариантов (т.е. веерная стрельба вместо методичной пристрелки к одной точке). Потом смотрим на результаты и брутфорсим наиболее удачное направление.
Одно другому не мешает. Найти поблизости такого же крутого дядьку как Пиз маловероятно, поэтому поучиться у него можно через книжки. Но живое общение с умными людьми тоже должно обязательно присутствовать. Оно заставляет мыслить гораздо интенсивнее.
Вероятно, вы что-то делали не так ;). Как говорят умные люди — неважно, как быстро вы бежите, если вы бежите не в ту сторону.
В представленном в статье примере товарищ Пиз явно имел ненулевую конверсию на небольших выборках, поэтому вполне имело смысл работать над количеством. Ещё раз повторю: работать над количеством надо только тогда, когда есть хотя бы минимальное качество.
Продаж, безусловно, будет больше. Но при этом надо учитывать цену привлечения клиента и те ресурсы, которые тратятся на обработку каждого этапа в воронке продаж (например, написать посетителю письмо). Поэтому, соотношение продажи / расходы скорее всего сильно уменьшится.
Хорошая иллюстрация воронки продаж. Но нельзя воспринимать этот совет слишком уж буквально.
Есть стандартный кейс: у вас продукт продаётся через вебсайт. Конверсия составляет, к примеру, 1%. Т.е. каждый сотый посетитель покупает ваш товар (что вполне себе неплохо). Вопрос, который встаёт перед вами, достаточно очевиден: как увеличить продажи?
Если бездумно использовать приведённый выше алгоритм, то появится огромное желание нагнать на сайт побольше траффика, т.е. повысить интенсивность. И кому-то гениальному приходит в голову мысль: «а давайте разместим баннер на порносайте». При этом траффик за три дня вырастает в пять раз, но продажи почему-то не увеличиваются. Почему?
Ответ очевиден: в данном примере мы исходили из того, что конверсия в 1% остаётся постоянной, независимо от качества привлечённых клиентов. На самом деле, это не так. Параметр конверсии напрямую зависит от того, кто именно пришёл на наш сайт. Одним из главных факторов конверсии является то, насколько удачно мы попали в нашу целевую аудиторию, насколько «качественный» траффик привлекли.
Очевидно, что уважаемый Алан Пиз не ошибается, когда говорит про интенсивность. Просто в его случае он работает только со своей целевой аудиторией (которая для продавца губок очень и очень велика) и не выходит за её пределы.
Такиим образом, фактор тщательности игнорировать нельзя ни при каких условиях. Тщательность нужна в том, чтобы определить кому звонить. А уж потом можно давить интенсивностью.
Вообще, смысл риск-менеджмента — предотвратить и уменьшить вероятность или тяжесть последствий риска, и проактивно ;) его мониторить. Сказать «У нас на проекте есть риск, что мы недооценили три фичи, поэтому, если что, я об этом говорил и не виноват» и на этом успокоиться — это не совсем про управление рисками. Это я типа на троллинг повёлся.
А если серьёзно, рассчёты «воронки проектов» — вещь предельно полезная для планирования.
Но в цифрах есть один нюанс:
Если разбить один большой этап на десять маленьких, вероятность успеха каждого будет выше, чем у исходного… (Ой, кажется я только что изобрёл agile). Какова вероятность сфэйлить 20-недельную «итерацию»? А 10 двухнедельных? А этапов будет аж на 9 больше.
Возможно, конечно я не понял призыв «не путать этап с итерацией». Тогда непонятно, как можно разбить задачу «Разработка дизайна домашней страницы» на несколько этапов.
Кстати, насчёт обмана: знаете, что на «нематериальную» мотивацию порой уходит в десятки раз больше времени и денег, чем на «материальную»? И кто кого обманывает в результате ;)?
Я не о том сказать хотел: вопрос не в том, что «работает только одно полушарие из двух» а в том, что в проекте у программиста и маркетолога-аналитика-продакта-заказчика (зовите как хотите) принципиально разные ценности. Сам долгое время работал программистом, кроме того, с несколькими десятками девелоперов взаимодействовал в роле ПМа, аналитика, продакта и заказчика. Ага, на вполне крупных промышленных проектах.
И наблюдения чисто статистически показывают: основная ценность для программиста — чёткая, структурированная система без костылей, красивый код, правильная архитектура. Я встречал очень мало программистов, которые готовы принести красивую архитектуру в жертву удобству пользователя, если их прямо не заставить так делать. И это нормально и правильно. Если программист не ценит нормальную архитектуру и красивый код, грош ему цена.
Но есть и другая категория — ПМы, продакты, заказчики, вышедшие из тех же программистов, и по старой памяти ценящие код, архитектуру и внутреннюю строгость системы выше удобства пользователя и общей юзабельности системы. Вот это уже сильно плохо, и это лечить надо. Как раз как тот «заказчик», который по вашей версии зафичекатил сохранение данных в гос. услугах (впрочем, что-то у меня большие сомнения, что такой вопрос вообще поднимался).
В общем, смело можете менять слова «левополушарное мышление» на «особенности логического мышления программиста, связанные с его профессиональной деятельностью», Может быть, так будет проще понять смысл статьи, не отвлекаясь на заезженные штампы
Кстати, в отличие от этой, предельно практическая. Так что, всем читать :).
По поводу доклада — давай спишемся. В целом очень «за», но есть пара нюансов
Я к тому, что не обязательно делать продукты для разработчиков, чтобы ими пользоваться. Я слышал замечательную историю о ребятах, которые для написания софта о логистике купили фуру и полгода колесили по стране.
Про встроенную штуку — вопрос немного более сложный. Кто её пользователи? Вероятно те, кто её встраивают. Сможете ли вы её встроить на самом деле? Сможете ли вы попасть на атомную станцию, чтобы протестировать софт для её оптимизации? Всё зависит от вас. И не акт, что получится. В этом случае придётся просто долго наблюдать их работу и представлять себя на их месте.
Некоторое время назад писал здесь текст о трёх уровнях развития программиста.
Данная статья великолепно иллюстрирует переход от второй ступени программиста — «сделаем всё и везде идеально и накрутим сложной архитектуры» (у меня есть знакомый, который называет таких товарищей «архирастами») — к третьей, которые понимают, что микроскоп — это микроскоп, а молоток — это молоток, и использовать микроскоп для того, чтобы забить гвоздь, только потому, что это более совершенный инструмент, смысла нет.
Я очень хорошо представляю такую ситуацию, так как не раз с ней сталкивался. Я бы не стал продолжать вкладывать ресурсы в брутфорс того, что не приносит никакой пользы. Обычно мы в таких случаях начинаем массово пробовать большое количество различных вариантов (т.е. веерная стрельба вместо методичной пристрелки к одной точке). Потом смотрим на результаты и брутфорсим наиболее удачное направление.
В представленном в статье примере товарищ Пиз явно имел ненулевую конверсию на небольших выборках, поэтому вполне имело смысл работать над количеством. Ещё раз повторю: работать над количеством надо только тогда, когда есть хотя бы минимальное качество.
Есть стандартный кейс: у вас продукт продаётся через вебсайт. Конверсия составляет, к примеру, 1%. Т.е. каждый сотый посетитель покупает ваш товар (что вполне себе неплохо). Вопрос, который встаёт перед вами, достаточно очевиден: как увеличить продажи?
Если бездумно использовать приведённый выше алгоритм, то появится огромное желание нагнать на сайт побольше траффика, т.е. повысить интенсивность. И кому-то гениальному приходит в голову мысль: «а давайте разместим баннер на порносайте». При этом траффик за три дня вырастает в пять раз, но продажи почему-то не увеличиваются. Почему?
Ответ очевиден: в данном примере мы исходили из того, что конверсия в 1% остаётся постоянной, независимо от качества привлечённых клиентов. На самом деле, это не так. Параметр конверсии напрямую зависит от того, кто именно пришёл на наш сайт. Одним из главных факторов конверсии является то, насколько удачно мы попали в нашу целевую аудиторию, насколько «качественный» траффик привлекли.
Очевидно, что уважаемый Алан Пиз не ошибается, когда говорит про интенсивность. Просто в его случае он работает только со своей целевой аудиторией (которая для продавца губок очень и очень велика) и не выходит за её пределы.
Такиим образом, фактор тщательности игнорировать нельзя ни при каких условиях. Тщательность нужна в том, чтобы определить кому звонить. А уж потом можно давить интенсивностью.
На самом деле, я как раз писал о том, что прежде чем назвать проект «неудавшимся», можно много чего ещё с ним сделать.
А если серьёзно, рассчёты «воронки проектов» — вещь предельно полезная для планирования.
Но в цифрах есть один нюанс:
Если разбить один большой этап на десять маленьких, вероятность успеха каждого будет выше, чем у исходного… (Ой, кажется я только что изобрёл agile). Какова вероятность сфэйлить 20-недельную «итерацию»? А 10 двухнедельных? А этапов будет аж на 9 больше.
Возможно, конечно я не понял призыв «не путать этап с итерацией». Тогда непонятно, как можно разбить задачу «Разработка дизайна домашней страницы» на несколько этапов.
Спасибо, у меня всё хорошо. Мне тоже стало жаль того времени, которое я потратил, пытаясь Вам что-то объяснить