Team Lead
0,0
рейтинг
24 августа 2011 в 15:35

Управление → Как делать нужные людям проекты, или почему не взлетают стартапы

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



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


1. Как важно увидеть проект глазами пользователя


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

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

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

Кстати, о важности логики говорит и Сергей Галицкий (кто не знает — миллиардер, создал с нуля (!) розничную сеть «Магнит») в программе Бизнес-секреты, и мы этой темы еще коснемся. В целом отмечу, что мне нравится высказывания Фрица Моргена, который не стал делить людей на логиков и интуитов, а высказал предположение, что у грамотных людей логика и интуиция работают последовательно, в одном цикле, сменяя друг друга.

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

Можно устранить ошибку, просто вовремя задумавшись
Можно устранить ошибку, просто вовремя задумавшись

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

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

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

Кажется, она опять попала в расширенный поиск
Кажется, она опять попала в расширенный поиск

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

Теперь вернемся к планированию итерации. Теперь вы знаете, что расширенный поиск — это будут две недели потерянного времени. В прямом денежном выражении — 10*N*S(i), где N — число программистов, S(i) — зарплата каждого за рабочий день. Например, для трех программистов с днем стоимостью $100 это будет 10x3x100 = $3000, то есть около 100 000 рублей! А если у вас еще есть конкуренты, которые за эти две недели сделают конкурентное преимущество — то потери будут несоизмеримо больше.

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

Таким образом, погружение в шкуру вашего пользователя дает вам:
1. Точное понимание важных задач в текущем моменте
2. Как следствие, возможность отсекать ненужный функционал еще на уровне обдумывания — если он не решает задач пользователя, его можно смело отсекать.


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

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

2. Как правильно общаться с программистами


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

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

Первое — программисту неинтересно. Это может быть либо в случае, когда человек занимается не своим делом (пришел из вебмастеров, работает тупо за деньги, и так далее), и ему вообще на все насрать, лишь бы платили. Но это — редкость. Второе — это руководитель не тратит время на вовлечение программиста, не показывает ему, что в проекте интересного, как важно то, что делается. Не дает фидбэк от пользователей. Чаще всего просто дает ТЗ и говорит — сделай так, как я сказал, и все. В то же время, если программисту объяснить проект с точки зрения пользователя, показать, какие вкусные и важные вещи делаются, поделиться с ним получаемой благодарностью — даже просто лог из аськи переслать «какой клевый раздел сделали!» от пользователя — программист начинает чувствовать свою активную роль в проекте, и гораздо лучше работает. Нужно просто делиться правдой и понимать важность вовлечение.

Второе — неработающий функционал. То же самое — если бы руководитель объяснял программисту, приучал его смотреть с точки зрения пользователя, выделял важные моменты, рассказывал логику — программист бы сам проверял, как все работает, и в 90% случаев тестировать не нужно было бы. По словам Макконнелла, мотивированный и немотивированный программисты отличаются в скорости до десяти раз.

Важность точного донесения информации до других участников проекта нельзя недооценивать
Важность точного донесения информации до других участников проекта нельзя недооценивать

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

По сути дела, описывать задачу нужно на языке программиста, и чем вы ближе по мышлению к техническому — тем проще вам будет. Идеальный вариант — это UML диаграммы (типа диаграммы последовательностей), которые легко можно рисовать от руки и быстро сканить (сканер стоит $100 и окупается в первую неделю, экономя в месяц вам часы разговоров — 90% информации передается визуально и лишь около 9-10% — на слух).

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

Дальше, нереальные сроки. Это также легко решается на уровне мышления. Прежде чем вам пришла мысль поставить задачу, нужно спросить себя, задать несколько вопросов:
1. Это можно не делать? Насколько можно отложить обдумывание, проработку этой задачи (проработкой я называю превращение мысли в точную постановку для программиста)?
2. Как это можно сделать проще?
3. Какие есть альтернативные варианты решения вопроса (вплоть до административных)?

Если выбор сделан, нужно работать с программистом. Для начала обсудите задачу голосом, спросите время. Допустим, в случае таблицы с фильтрами вы услышали — 23 часа, а нужно сделать задачу на 4 часа. У вас три фильтра — выпадающие списки по стране, курорту и дате, и таблица выводит записи. Просите программиста расписать этапы задачи, даете полчаса подумать, получаете список:
— словарик курортов, стран на уровне базы с админкой — 8 часов
— календарик для выбора даты — 1 час
— сортировки в таблице — 4 часа
— выборка из БД и вывод из таблицы — 2 часа
— пейджинг — 4 часа
— фильтр по дате, стране, курорту — 4 часа

Задавая наводящие вопросы по непонятным пунктом, помня про реально важный функционал, а также прикидывая, как будет выглядеть задач на живых данных, говорите делать следующие этапы
1. Так как записей будет не более 100, пейджинг не нужен
2. Так как будут фильтры и записей немного, сортировки (которые программист легко сам включит в список) не нужны
3. Так как реально стран будет две, курортов меньше 10, а смотреть в большей части случаев записи нужно за вчера — говорите сделать для начала прямо хардкодом (массивом в коде) страны и курорты и вчерашний день, без календарика
4. Зная, что программист в среднем оптимистичен на 100%, говорите ему, что самым важным является просто вывод данных из базы в виде простой таблицы, которую можно набросать ему самому на 5 минут на голом HTML (экономим время, верстку прикрутим потом), и даете 2 часа. В итоге за 4 часа он сделает то, что вам нужно.
5. Заверяете его, что будет дано время на рефакторинг.

И таким образом — с каждой задачей, пока вы не получите на 80-90% то, что вам нужно. Тогда переключаетесь на другого программиста и другую задачу, а текущему даете отрефакторить. Здесь все в выигрыше: и вы сначала, очень быстро делаете несколько итераций на живых данных, и получаете конечный вид и логику системы, и программист — он не будет писать долго то, что потом придется переделывать (ведь вы еще не сделали микроитерации, чтобы точно понять, как нужно правильно), а говнокодом (нужно иногда продавить быстрый вариант, показать выгоду) сделает пару итераций, получит очень точный вариант задачи, и сможет ее отрефакторить, имея уже точное понимание, как там все устроено.

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

Все вышеописанное — это, конечно, микроменеджмент, но это позволяет делать релизы каждый день на ранних стадиях проекта и на 80-90% точный функционал. Если вы знаете подход, который лучше позволяет на первом этапе действовать — опишите в комментариях.

3. Почему любой проект нужно постоянно развивать



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

Иногда проекту штаны становятся уже не по размеру
Иногда проекту штаны становятся уже не по размеру

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

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

Подводим итоги


1. Самое важное — правильно мыслить. Уметь взглянуть на проект глазами своего пользователя и тем самым понимать реально важные задачи, и то, как эти задачи нужно сделать. Стартапы не взлетают потому, что делают неправильный функционал, не нужный никому, и теряют деньги и время.
2. На 90% проблемы в проектах — ошибки в следствие неверного менеджмента.
3. Правильная мотивация, вовлечение программиста, проработанная постановка задач и плотная работа с программистом по определенной методологии позволяют ускорить до 10 раз и делать на 80-90% нужный функционал точно в срок, при этом выделяя время на рефакторинг для программиста
4. Любой проект нужно развивать, чтобы он жил.

Желаю Вам удачи и предлагаю поделиться своим опытом в комментариях.

Кросспост в моем ЖЖ
@Cord
карма
403,5
рейтинг 0,0
Team Lead
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (48)

  • +2
    Вот потом веселье из такого хардкоденого фильтра делать конфетку. Особенно когда из таких хардкодов состоит весь проект.
    • +9
      Если состоит весь проект — опять же, косяк менеджера.
      Обязательно нужно давать время на рефакторинг, и раз в неделю минимум спрашивать самому — может, что-то отрефакторить нужно, давай выделю время.

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

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

      Говнокод и харкод — не значит полный ппц. Просто какие-то вещи не делаются заранее, лишь намечаются. Как в том примере с массивом — вы наметили массив стран в коде. Потом просто у вас будет не ['Египет', 'Турция'], а что-то вроде CountriesList (new CountryRepository()).getCountries() (псевдокод).
      Первые два дня побудет и массив, а дальше, когда уже сам функционал и логика устоится — можно нормально переписать. Просто если сразу писать нормально, а потом по пять раз переделывать — так как не устоялся функционал в мелочах (которые могут тянуть серьезные изменения внутри), то время разработки суммарное будет в несколько раз больше.

      Подчеркиваю — это лишь для случая, когда идет изначальная разработка проекта, быстрая причем. В случае неторопливой допилки этого, конечно, можно не делать.
      • 0
        Согласен, что это косяк менеждера. Но в реальности над менеджером часто стоят директора, инвесторы и пр. «не особо вникающие» личности с логикой «так работает же! зачем тратить еще 600% денег на рефакторинг?». В описанном примере как раз в 6 раз задача была упрощена.
        • +6
          это тоже работа менеджера.
          нужно с каждым говорить на его языке.

          слово «рефакторинг» такое же чужое, как и фраза «сфокусируй звук во лбу за счет подачи дыхания в одну точку, попробуем на И» (из оперного вокала).

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

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

          поэтому важна не сама суть, сильно важнее — умение ее подать.
          • +2
            можно «сымитировать» баги
            нельзя. это обман, а обманывать — неправильно.
            • 0
              если у вас нет другого выхода,
              выбирая между 100% загубленным проектом, из-за непонимания руководством нужд (И причем вы же и будете виноваты, что после определенной стадии проект нужно переписывать с нуля, а каждая новая функция ломает существую),

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

              но могу сказать, мне как-то сильно повезло, у нас гендиректор понимает необходимость рефакторинга и не возражает против него.
              • 0
                если у вас нет другого выхода
                два выхода есть, даже если вас съели ;)
                если серьёзно — то это уже не обман. ну или заводить трактор со словами «@#$тесь сами»
          • +1
            Просто друг фанатик, а юзеры Гэлэкси — нет.
            Многие юзеры айфона тоже фанатизмом не страдают. :)
      • +1
        И после каждой задачи, особенно если начальный этап, время давать привести в порядок.

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

        задело за живое. спасибо большое.

  • +3
    Вот достался мне тут на допиливание проект, с таким же временным массивом на 200+ строк, причем часть функционала работает с этим массивом именно в том виде, в каком он есть. В итоге я просто «доклеил» массив выборкой из базы, так как нужно было реализовать функционал изменения части настроек из админки.
  • +1
    Про вовлечение программиста это очень верно. У нас программисты так вовлечены что им все завидуют и чувствуют себя ненужными. У меня руки тоже чешутся, хочется поучаствовать.
  • +4
    Откуда столько советчиков появилось последнее время? Что каждый из них магистр психологических наук и уже не первый фэйсбук сделал?
    • –2
      Прочтение нужной статьи в нужное время может ускорить эволюцию.
      • +1
        хорошо, предложите методологию лучше, которую вы применяли на практике.
  • +38
    image
    Кажется, ее монитор забыли подключить к системному блоку и в 220V.
    • +3
      анекдот вспомнился.
      xxx: Наша офисная сотрудница уснула, сидя за компом. Спала долго. Тут заходит директор, сотрудница просыпается и начинает изображать бурную деятельность, по клаве долбит, мышку дёргает. xxx: Директор говорит: «Люда, у нас уже полтора часа света нету».
    • +7
      А она все ждет, когда же загрузится расширенный поиск.
    • +5
      Раджагопал Рохит (Rajagopal Rohit), 29-летний менеджер одной из туристических фирм Дели, прославился на весь мир тем, что три года проработал за компьютером, не включая монитор.

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

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

      На изучение компьютера у молодого человека ушло примерно два месяца.

      «Я никак не ожидал, что компьютер окажется такой сложной и неудобной машиной», — признался Рохит, вспоминая этот период своей жизни.

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


      www.lapsha.ru/articles/tech/2003/12/05/094700.html
      • +1
        да он, должно быть, гений шоткатов
        • 0
          Это компьютерная йога :)
    • 0
      И мышку не дали.
    • +5
      фотограф — кретин
      такое даже на фотостоки стыдно выставлять
  • 0
    Прям спасибо.
    Без иронии
  • +7
    Вот только не приводите такие примеры:
    >кто не знает — миллиардер, создал с нуля (!) розничную сеть «Магнит»

    Вы меня извините, но Магнит это потогонная фабрика. В ряде компаний есть внутреннее правило для HR не брать людей из Магнита. Я не знаю как Этот миллиардер основал эту сеть. Но я четко знаю, что она вредна для общества.

    Думаю я потеряю свою карму, но не надо сравнивать сетевика с IT. Тем БОЛЕЕ В РОССИИ, где IKEA сталкивается с проблемами, ут нет eMashines и так далее. Зато Магниты с кубаноидским подходом есть. Уверен в нормальной стране ониб умерли.
    • +1
      я думаю, в нормальной стране они бы поднялись в два раза быстрее, потому что не надо было решать те проблемы, которые тормозят им бизнес (а таким тепличным компаний, типа Икеа, и вовсе не дают работать нормально).
      в целом, я не хочу углубляться в эту тему. но можно сказать, что икеа — это такие академически тренированные на лучших тренажерах мира легкоатлеты. а российский бизнес в целом — это такой худющий негр-марафонец, который в нищей африке быстрее всех только потому, что от львов бегать приходится, чтобы не сожрали. и в честном бою, конечно, этот негр на раз-два делает академически тренированных бегунов — да потому что жить охота. как представит сзади Лёву — только его пятки и видали :)

      метафора, конечно, неточная, но смысл понятен, надеюсь.

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

      такие дела.
      • –1
        Я не говорю про о, что и как снаружи Магнита. Но внутри люди это даже не пешки…
        Если он миллиардер пусть хоть на 3000 ЗП подымет и улучшит условия работы. Я там не работаю, но это… Слов нет.

        У тебя сотрудники воют? Нет или да? А там люди как хомячки в лаборатории… Кк и в Связном.
        • +1
          Не воют :)
          У меня не магнит :)

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

          Но даже так, смотри, что говорит Потапенко.
          Брал таджиков, у которых ниже уровень потребления. За 7-10 штук работают отлично, ни одного нарекания. И тут блядь в Твери выходит приказ — запрещено брать иностранцев.
          Все, берет на 15 штук тверичей (тверян, тверитян — я слышал три разных слова для обозначения жителей города). И они — что ты думаешь? Тупо бухают, зная, что их нельзя уволить, таджиков-то не возьмешь на их места. Резко упала производительность, прогулы и так далее. Вопросы есть? В регионах, особенно в селах разных, народ страшно бухает. Ты будешь просто так платить деньги из своего кармана, когда у тебя человек на неделю в запой ушел, и ты сам стоял за прилавком, за троих работал? Какого хуя?

          • 0
            Правда, и работодатели бывают охуевшие.

            Вот недавно случай — человеку платят 12 тысяч в регионе, пашут на нем как на админе, дизайнере, программере. Они чего, ебанулись? Да 20 тысяч на удаленке он легко найдет работу, хотя бы немного мониторили рынок.

            Работников интеллектуального труда нужно ценить, особенно в регионах. Этого, увы, там пока не понимают «бизнесмены». Бизнесмены тоже разные бывают — от любителей и нубов, до суперпрофи.
      • +1
        Я без обид. Статья очень полезная. Но я как бы вижу Магнит, как и другие Краснодарские конторы. У многих все в работе полный раздрай, но могу поспорить Магнит может стать Икеей. Толко по нашему русскому обычаю: Зачем стараться строить бизнес в рассчете на будущее — его отберут всеравно!

        А так статья годная и спасибо это меня торкнуло :-)
        • 0
          Окей, я согласен, пример, может быть, неудачный. Понимаете, очень трудно смотреть с обоих сторон.
          С одной, я бы всем платил огромные деньги. С другой, я понимаю, что один работает по 12 часов и результаты выдает, а другой в семь ушел — и его нет, только спрашивает когда же ЗП поднимут и вечно недоволен, при этом за ним всегда доделывают и баги.

          Нельзя всем платить одинаково хорошо, Зарплата должна быть из оклада + бонус, четкий за результаты, на основе KPI.
        • 0
          Спасибо, я старался.
          Еще вчера задумал, перед сном.
    • –1
      Знаете, Галицкие, достойные бизнесмены, и достоинство его в том, что он не украли ваши деньги и построил себе бизнес, как большинство, олигархов наших, а сам развил свою сеть, выбрал нишу потенциальных покупателей, и на них ориентировал свой бизнес. Начинал с братом и отцом, с ларька и склада(у отца) т.е. по сути он развил бизнес отца(дальше о Сергее пойдет речь). Уделил важное внимание логистике, чуть ли не с момента когда у него стало больше одного магазина. Так что, вполне достойный пример.
      Так же сравните с сетью пятерочки (копеечка) в чем разница для конечного потребителя?
      p.s. надеюсь, что вам не сольют карму, ибо вы, просто высказали свое мнение.
      В споре рождается истина.
      • 0
        Кстати о особенности кубанойдского управления согласен на все 100 %.
        Ибо знаю кухню, очень разных организаций. Ну и сам кубанойд так сказать.
  • +3
    >>Критерий один — после прочтения задачи у программиста не должно возникать вопросов. Вообще.
    Куда вам памятник поставить?
    • –4
      Даже не знаю, ирония ли это :)

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

      а так — отвечу словами Пушкина :)

      Я памятник себе воздвиг нерукотворный,
      К нему не зарастет народная тропа,
      Вознесся выше он главою непокорной
      Александрийского столпа.
      Нет, весь я не умру — душа в заветной лире
      Мой прах переживет и тленья убежит —
      И славен буду я, доколь в подлунном мире
      Жив будет хоть один пиит.
      Слух обо мне пройдет по всей Руси великой,
      И назовет меня всяк сущий в ней язык,
      И гордый внук славян, и финн, и ныне дикой
      Тунгус, и друг степей калмык.
      И долго буду тем любезен я народу,
      Что чувства добрые я лирой пробуждал,
      Что в мой жестокий век восславил я свободу
      И милость к падшим призывал.
      Веленью божию, о муза, будь послушна,
      Обиды не страшась, не требуя венца;
      Хвалу и клевету приемли равнодушно,
      И не оспоривай глупца.
  • 0
    У меня ещё нет успешных проектов, но я стараюсь задачи для программистов ставить только после полной реализации интерфейса для задачи («разработка от центра»), читай по результатам работы пары: дизайнера и верстальщика.
    Такой подход поддерживают и ребята из 37signals.
    Это и быстро (для менеджера), и наглядно (для пользователя), и доступно (для программиста).
    Под вопросом пока остаётся увлечённость для программистов, у меня ещё нет «статистики». Но думаю, что её можно будет компенсировать фидбэком от пользователей.
  • 0
    стартап — проект, который требует веры и блеска в глазах. Поэтому вовлечение программистов — очень важный момент.
    И еще, стартап «дает волю» мозгам программистов.
    На обычном проекте, с четкими сроками и постановкой, они так не «извращаются», как на стартапах. На стартапах не просто полет мысли, а еще и реализуют они свои мысли быстро, не пытаясь увеличить их стоимость, а напротив, как бы борясь за то, чтобы идея была реализована.
  • 0
    Меня в микроменеджменте смущают 2 проблемы:
    1. руководитель влезает со своими задачами во время решения программистом другой задачи и часто приходиться браться за новую, не завершив старую. Что, понятно, не ускоряет общую работу. И тут не скажешь, что руководитель плохой. Просто в силу специфики микроменеджмента и задачи, которые ставятся, часто бывают микро. И они не могут ждать день-два-три.
    2. Если руководитель постоянно участвуют в уточнении поставленных перед программистом задач (а, как мы помним, они микро и их объём измеряется в часах), то часто возникает ситуация, когда программист вынужден ждать, пока руководитель освободиться от других своих дел (например, шеф вызвал, к заказчику поехал и т.п.). И тогда описанная Вами экономия времени может растаять без остатка.

    Как Вы разруливаете эти проблемы?

    P.S. По-моему Макконнелл говорил не про мотивированных программистов. Он говорил, что скорость работы среднего и лучшего программиста может различаться в скорости в 10 раз.
    • 0
      — программист решает одну задачу в потоке. за это отвечает руководитель.
      ну то есть задачи идут последовательно

      — на это не должно уходить больше часа в день. утром продумал и все.
  • 0
    Так программистов у вас наверное много? И что делает программист, когда закончил задачу? Ждёт, когда у Вас будет время разобраться с новой задачей для него? Пусть даже он знает, какая его следующая задача. Но если он сам возьмётся за следующую задачу, он может начать её делать так, что потратит 23 часа, а не 5, как Вам бы хотелось.
    • 0
      для этого есть пул задач, заранее проработанных.

      и потом, проработать задачу — от 10 минут до часа.
      а сделать ее — от 4 до 8 часов.

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

      в общем и целом, короче, эта методика работает для условий релиза каждый день и некритичного функционала. вот только сегодня с коллегой обсуждали, у него один продукт, зато какой: нагрузка колоссальная, highload, и функционал важный, нельзя выкатывать не проверенный вдоль и поперек. там вот эта моя метода, конечно, не канает. там другая методика разработки.
  • 0
    Спасибо, познавательно.
  • 0
    >> 5. Заверяете его, что будет дано время на рефакторинг.
    Если Ваши слова расходятся с делом, то очень быстро Ваш программист перестанет Вам верить. А это файл на ранних стадиях.

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