интересно, а что получится, если ноги двигать не парами, а в более сложной логике. Например, если шаг это 6 тактов, то сейчас начало цикла у каждой ноги —
1 4
4 1
1 4
почему бы не сделать например вот так:
1 4
5 2
3 6
тогда доля от экономии означает, что доделав вы спасли себя от, допустим, 50000 убытков из вашего кармана. Потому что доля — это еще и доля в рисках/убытках. В этот момент почему то все сразу сливаются на ставку.
есть такой принцип, отчасти за него Герберт Саймон получил нобелевскую премию — называется принцип ограниченной рациональности: человек выбирает не лучший вариант, а первый хоть сколько-ниубдь подходящий. Таким образом, если человек находит что-либо, например жилищные условия, пусть с кучей оговорок, но приемлемыми и мирится с ними, он практически наверняка не предпримет реальных действий что бы их изменить. Если, при этом, он частично понимает, что живет не очень — он скорее придумает сложную теорию о том, почему так, нежели начнет, черт побери, что-то делать.
Опыт — штука хорошая, да. Но только в «строгих дисциплинах». Опыт решения дифура — бесценен. Опыт же клевой вечеринки несет сомнительную пользу — повторить ее едва ли получится. Говоря иначе (и в этом я полностью убежден) — абстрактный «опыт» — чушь собачья. Рулят, с одной стороны, рецепты по получению определенного результата. А с другой стороны, набор убеждений (все знакомые мне люди, которые добились выдающихся результатов, убеждены, что окружающий мир полон разнообразных возможностей). В вашей статье, со всем уважением, я не увидел ни рецепта по получению некоего результата, ни тех убеждений, которые можно было бы перенять. Потому и ассоциации соответствующие, вы уж простите за прямоту.
Облака — не, не революция?
Компании с горизонтальной системой управления — не, не революция?
Геолокация — не, не революция?
Тач-интерфейсы — не, не революция?
Порошок, регенерирующий палец человеку — не, не революция?
Если смотреть вместо всего многообразия окружающего мира только на то, что проплывает перед носом — люди будут злыми и алчными.
Гугл — на тенисные столы приходят не профессионалы?
Монахи шаолиня — их тоже мотивируют деньги? или, быть может, они все глубоко несчастны?
Ничего личного, просто нелюбовь к нытью.
Не знаю, каких вы там людей навстречали, но одно скажу точно: люди боятся амбициозных перемен. Если и решаются на новое, то выбирают то же дерьмо, только в профиль. В квартире течет потолок? Терпим. Задроло терпеть — хаем соседей. Решили всеже переехать — ни копейкой дороже. Сосед снова ** — парадокс.
Менеджер по развитию бизнеса в 23 — не бро. А бизнесмен с доходом 6Круб/мес в 28 тогда бро?
Ау. Смотрите на жизнь шире, а не рефлексируйте над своим прошлым опытом.
и все же. Вас мотивирует возможность не думать, или же все же просто жизнь на определенном уровне комфорта?
И да, «любимое дело» ничуть не менее обобщенное понятие, чем «работа». Хотя оно и говорит чуть больше о соискателе, но если бы я хотел бы понять, как именно этот соискатель может улучшить работу фирмы работая в ней — меня бы такой ответ всеравно не устроил бы, и я продолжу копать: «какие именно дела вы считаете любимыми?».
перефразирую: работа — слишком обобщенное понятие. Мотиватором выступает не сама работа, а определенный ее аспект. И чем лучше и работодатель и соискатель понимают, что это за аспект, тем продуктивнее их сотрудничество.
К сожалению, зачастую сосикатели сами не понимают что ими движит (или не хотят признавать/признаваться), и тут вся надежда компании на профессионализм проводящего собеседование.
«Помним, что основной мотиватор — это сама работа» — сомнительно. Если точнее, то точно нет. Работа не может быть мотиватором. Как не может быть мотиватором и зарплата.
Если соискатель сам говорит, что «хочу работу. хочу денег», значит он слишком зашорен. Он скучен и узколоб.
Мотиватором может быть либо конечный результат работы («я создам крутое решение», «я смогу получить уважение своего учителя, если устроюсь рботать в крутую компанию», «я заработаю на машину, засчет которой мне даст вон та телочка» (да, бывает и такая мотивация), либо некий процесс («я решаю интересные задачи», «я работаю с душевными людьми», «до этой работы я каждый день езжу на велосипеде») и даже может быть просто по фану («я влядею долей в бизнесе и мне хватает денег, но я просто люблю программировать и потому с интересом буду делать это у вас» (отчасти шутка. Я такие варианты встречал, но не в IT, хотя чем черт не шутит)).
И это первая часть. Намерение соискателя.
Теперь вторая. Намерение работодателя. Как верно замеченно — «зачем ищем сотрудника». И это нельзя отдавать на откуп сомнительной эйчарне. Намерение работодателя — это тот результат, который он хочет от работника, будь то единовременное большое задание или постоянно выполняемая работа.
И третье: а что вообще и как вокруг. Если вы ищите там, где мало претедентов и их уровень невысок — то, наверное, главным критерием будет обучаемость. Если ищите среди множества профессионалов, то вступают в дело вторичные факторы, как то уживчивость, коммуникабельность и любимая футбольная команда.
Эти три пункта есть условие задачи. Пока они не определены — любые тестовые задания на час или на месяц, испытательные сроки, вопросы, рассказы и прочая лабуда бессмысленны, как бессмысленна формула дискриминанта для тригонометрического уравнения.
И тогда вопрос — как определить чего хочет соискатель? как определить чего хотим мы? и как вообще понять что к чему сейчас в наших краях? а этого инстрментария в статье нет. Увы.
Но, в любом случае, автору спасибо за желание делиться своим опяытом. Он, однозначно, любопытен.
Тем не менее был как минимум в двух ситуациях.
Первая — когда некую аналитическую систему переписал с нуля один человек за две недели переписал с нуля с учетом новых требований, в то время как «развернутую и работающую» пытались доработать 3 месяца.
Вторая, когда переписаная с нуля система (семантическое ядро) в 5 раз обогнала на настольном компе рабочую у развернутую на мейнфрейме.
Я НЕ утверждаю, что перписывать хорошо. Однако, работая аналитиком, привык к фактам и привык не доверять утверждениям «считаю, что так правильно».
На мой взгляд требуется внятная методика оценки поддержки системы, что бы манипулировать такими примерно цифрами:
«Итак. Есть вариант дописывать к текущей — и каждая доработка будет стоит $100. И есть вариант переписать за $900 со внятной архитектурой и тогда каждая доработка будет стоить $10. И тогда если требуется < 10 доработок выгоднее дописывать старую, а если больше, то выгоднее переписать»
И никаких вам «да в чо, он нормальный программист» и «да я вам как эксперт говорю» и прочих разрываний тельняшек.
Тема не раскрыта. К сожалеию.
Lean это 5 (пять) принципов:
* Создание ценности (рассказано)
* Работа с потоком (рассказано чутка)
а вот про
* организация потока (выравнивание, время цикла)
* вытягивание (ключевое, на мой взгляд, отличие Lean от другого менеджмента по-уму)
* постоянное улучшение
да. просто, к сожалению, применение аналитики на умозрительных фактах сродни интеллектуальной мастурбации. Движение есть, результата нет. (простите мне мою резеость)
Первое — это, как я уже написал к исходной статье «взаимоисключительность и полнота», или же MECE.
Второе — факты и типизации. Их можно проверять, к примеру, на критерии научности:
Повторяемость, независимоть от проверяющего и бритва оккама.
И, кстати, я вообще не увидел ничего об измеримых последствиях реализации риска. Предположим, я убежденный глобалист, и тогда из этого отчета мне в принципе не ясно, не только чем грозит R04, но почему это вообще риск? Каковы _измеримые_ последствия реализации этого риска?
На мой взгляд очень не хватает взимоисключительности и полноты. (Того, что часто называется MECE).
Тоесть, что пункты в дереве рисков не должны пересекаться, раз
и дерево должно охватывать все возможности, это два.
Особенно печально с первым пунктом.
Может получиться, что, например, некий красный риск будет учтен дважды под разными названиями, по-отдельности проанализирован и вероятность его возникновения (под одним или другим названием) будет переоценена.
Так же, лично я бы добавил учет длительных эффектов как от воздейстия события, так и от методов реагирования. Так, например, при посевной риск паразитной инвазии весьма актуален. И в рамках одного проекта (собственно, конкретной посевной) логично применять самые ядреные пестециды, какие есть. В то же время они негативно скажутся на следующих посевных, а в методике с этим не работают.
В-третьих мне не понравилась методика оценки работы риск-менеджера. Велик соблазн учитывать риск штуками, а не последствиями. Я бы предпочел «истрачено меньше 50% запланированых ресурсов на погашение рисков — хорошо, премию. больше 50 но меньше 100 ста — нормально. Больше 100 — плохо», хотя и этот метод не учитывает эффективность _первоначального_ планирования.
Но в любом случае спасибо за статью — весьма любопытно.
пока еще не изучил исходную методику (сейчас почитаю), но в статье настораживает очень низка подкрепленность фактами.
Первое, что насторожило, это «мозговой турм в ЖЖ». Как известно, «опрос интернете показал, что интеренотом пользуются 100%», а в опросе «орел или решка» побеждает первй вариант. И скорее можно говорить не о объективных данных, а о субъективном мнении, созданым лидерами мнений.
А уж использование противоречащих предпосылок (хотел было сказать «фактов») в разных пунктах — так вообще ах. В R01 «население с высокими образовательными показателями» противоречит R03, а предшестующий тезис «развитая инфраструктура» всупает в некоторое противоречие с R04.
Есть и еще некоторое количество совсем уж явных методологических ошибок.
Ни в коем случае не критикую. Так, в качестве обратной связи. Раз уж заявлено, что это было упражнением.
Идеи здравые, но, к сожалению, очень обрывочно изложенные.
Например, нигде не сказано про ценность, создаваемую проектом для заказчика. По идее, оно скрыто под «цели и задачи», но именно в этом пункте я и вижу основные провалы.
Цели и задачи должны быть явно измеримы и метрика на них должна оговариваться сразу, к примеру «сокращение времени обработки заказа вдвое», а не, как любят говорить «улучшение клиентского сервиса»
Количество строк кода — не метрика вообще. Тоесть формально, она что-то измеряет, но непонятно что.
Есть распространенное название для разного рода метрик в упралении — KPI, или «ключевые индикаторы ЭФФЕКТИВНОСТИ», а количество строк кода не имеет ничего общего с эффективностью.
Отсюда следует, что главный принцип не «не навреди», а «реши, зачем меряешь», или, на шаг веперед, «определи, какие решения хочешь принимать».
На мой взгляд — индивидуальные метрики в разработке вообще мало осмыслены. Только групповые. Например, безбажность кода применима не к программисту лично а к связке программист+тестер, так как с точки зрения управления не сделаная ошибка или исправленная — одно и то же, если на это ушло одинаковое количество времени (в этом примере я упрощаю).
1 4
4 1
1 4
почему бы не сделать например вот так:
1 4
5 2
3 6
Опыт — штука хорошая, да. Но только в «строгих дисциплинах». Опыт решения дифура — бесценен. Опыт же клевой вечеринки несет сомнительную пользу — повторить ее едва ли получится. Говоря иначе (и в этом я полностью убежден) — абстрактный «опыт» — чушь собачья. Рулят, с одной стороны, рецепты по получению определенного результата. А с другой стороны, набор убеждений (все знакомые мне люди, которые добились выдающихся результатов, убеждены, что окружающий мир полон разнообразных возможностей). В вашей статье, со всем уважением, я не увидел ни рецепта по получению некоего результата, ни тех убеждений, которые можно было бы перенять. Потому и ассоциации соответствующие, вы уж простите за прямоту.
Компании с горизонтальной системой управления — не, не революция?
Геолокация — не, не революция?
Тач-интерфейсы — не, не революция?
Порошок, регенерирующий палец человеку — не, не революция?
Если смотреть вместо всего многообразия окружающего мира только на то, что проплывает перед носом — люди будут злыми и алчными.
Гугл — на тенисные столы приходят не профессионалы?
Монахи шаолиня — их тоже мотивируют деньги? или, быть может, они все глубоко несчастны?
Ничего личного, просто нелюбовь к нытью.
Не знаю, каких вы там людей навстречали, но одно скажу точно: люди боятся амбициозных перемен. Если и решаются на новое, то выбирают то же дерьмо, только в профиль. В квартире течет потолок? Терпим. Задроло терпеть — хаем соседей. Решили всеже переехать — ни копейкой дороже. Сосед снова ** — парадокс.
Менеджер по развитию бизнеса в 23 — не бро. А бизнесмен с доходом 6Круб/мес в 28 тогда бро?
Ау. Смотрите на жизнь шире, а не рефлексируйте над своим прошлым опытом.
И да, «любимое дело» ничуть не менее обобщенное понятие, чем «работа». Хотя оно и говорит чуть больше о соискателе, но если бы я хотел бы понять, как именно этот соискатель может улучшить работу фирмы работая в ней — меня бы такой ответ всеравно не устроил бы, и я продолжу копать: «какие именно дела вы считаете любимыми?».
К сожалению, зачастую сосикатели сами не понимают что ими движит (или не хотят признавать/признаваться), и тут вся надежда компании на профессионализм проводящего собеседование.
Если соискатель сам говорит, что «хочу работу. хочу денег», значит он слишком зашорен. Он скучен и узколоб.
Мотиватором может быть либо конечный результат работы («я создам крутое решение», «я смогу получить уважение своего учителя, если устроюсь рботать в крутую компанию», «я заработаю на машину, засчет которой мне даст вон та телочка» (да, бывает и такая мотивация), либо некий процесс («я решаю интересные задачи», «я работаю с душевными людьми», «до этой работы я каждый день езжу на велосипеде») и даже может быть просто по фану («я влядею долей в бизнесе и мне хватает денег, но я просто люблю программировать и потому с интересом буду делать это у вас» (отчасти шутка. Я такие варианты встречал, но не в IT, хотя чем черт не шутит)).
И это первая часть. Намерение соискателя.
Теперь вторая. Намерение работодателя. Как верно замеченно — «зачем ищем сотрудника». И это нельзя отдавать на откуп сомнительной эйчарне. Намерение работодателя — это тот результат, который он хочет от работника, будь то единовременное большое задание или постоянно выполняемая работа.
И третье: а что вообще и как вокруг. Если вы ищите там, где мало претедентов и их уровень невысок — то, наверное, главным критерием будет обучаемость. Если ищите среди множества профессионалов, то вступают в дело вторичные факторы, как то уживчивость, коммуникабельность и любимая футбольная команда.
Эти три пункта есть условие задачи. Пока они не определены — любые тестовые задания на час или на месяц, испытательные сроки, вопросы, рассказы и прочая лабуда бессмысленны, как бессмысленна формула дискриминанта для тригонометрического уравнения.
И тогда вопрос — как определить чего хочет соискатель? как определить чего хотим мы? и как вообще понять что к чему сейчас в наших краях? а этого инстрментария в статье нет. Увы.
Но, в любом случае, автору спасибо за желание делиться своим опяытом. Он, однозначно, любопытен.
Первая — когда некую аналитическую систему переписал с нуля один человек за две недели переписал с нуля с учетом новых требований, в то время как «развернутую и работающую» пытались доработать 3 месяца.
Вторая, когда переписаная с нуля система (семантическое ядро) в 5 раз обогнала на настольном компе рабочую у развернутую на мейнфрейме.
Я НЕ утверждаю, что перписывать хорошо. Однако, работая аналитиком, привык к фактам и привык не доверять утверждениям «считаю, что так правильно».
На мой взгляд требуется внятная методика оценки поддержки системы, что бы манипулировать такими примерно цифрами:
«Итак. Есть вариант дописывать к текущей — и каждая доработка будет стоит $100. И есть вариант переписать за $900 со внятной архитектурой и тогда каждая доработка будет стоить $10. И тогда если требуется < 10 доработок выгоднее дописывать старую, а если больше, то выгоднее переписать»
И никаких вам «да в чо, он нормальный программист» и «да я вам как эксперт говорю» и прочих разрываний тельняшек.
Lean это 5 (пять) принципов:
* Создание ценности (рассказано)
* Работа с потоком (рассказано чутка)
а вот про
* организация потока (выравнивание, время цикла)
* вытягивание (ключевое, на мой взгляд, отличие Lean от другого менеджмента по-уму)
* постоянное улучшение
не сказано ничего. И это печально.
Первое — это, как я уже написал к исходной статье «взаимоисключительность и полнота», или же MECE.
Второе — факты и типизации. Их можно проверять, к примеру, на критерии научности:
Повторяемость, независимоть от проверяющего и бритва оккама.
И, кстати, я вообще не увидел ничего об измеримых последствиях реализации риска. Предположим, я убежденный глобалист, и тогда из этого отчета мне в принципе не ясно, не только чем грозит R04, но почему это вообще риск? Каковы _измеримые_ последствия реализации этого риска?
Тоесть, что пункты в дереве рисков не должны пересекаться, раз
и дерево должно охватывать все возможности, это два.
Особенно печально с первым пунктом.
Может получиться, что, например, некий красный риск будет учтен дважды под разными названиями, по-отдельности проанализирован и вероятность его возникновения (под одним или другим названием) будет переоценена.
Так же, лично я бы добавил учет длительных эффектов как от воздейстия события, так и от методов реагирования. Так, например, при посевной риск паразитной инвазии весьма актуален. И в рамках одного проекта (собственно, конкретной посевной) логично применять самые ядреные пестециды, какие есть. В то же время они негативно скажутся на следующих посевных, а в методике с этим не работают.
В-третьих мне не понравилась методика оценки работы риск-менеджера. Велик соблазн учитывать риск штуками, а не последствиями. Я бы предпочел «истрачено меньше 50% запланированых ресурсов на погашение рисков — хорошо, премию. больше 50 но меньше 100 ста — нормально. Больше 100 — плохо», хотя и этот метод не учитывает эффективность _первоначального_ планирования.
Но в любом случае спасибо за статью — весьма любопытно.
Первое, что насторожило, это «мозговой турм в ЖЖ». Как известно, «опрос интернете показал, что интеренотом пользуются 100%», а в опросе «орел или решка» побеждает первй вариант. И скорее можно говорить не о объективных данных, а о субъективном мнении, созданым лидерами мнений.
А уж использование противоречащих предпосылок (хотел было сказать «фактов») в разных пунктах — так вообще ах. В R01 «население с высокими образовательными показателями» противоречит R03, а предшестующий тезис «развитая инфраструктура» всупает в некоторое противоречие с R04.
Есть и еще некоторое количество совсем уж явных методологических ошибок.
Ни в коем случае не критикую. Так, в качестве обратной связи. Раз уж заявлено, что это было упражнением.
Например, нигде не сказано про ценность, создаваемую проектом для заказчика. По идее, оно скрыто под «цели и задачи», но именно в этом пункте я и вижу основные провалы.
Цели и задачи должны быть явно измеримы и метрика на них должна оговариваться сразу, к примеру «сокращение времени обработки заказа вдвое», а не, как любят говорить «улучшение клиентского сервиса»
Есть распространенное название для разного рода метрик в упралении — KPI, или «ключевые индикаторы ЭФФЕКТИВНОСТИ», а количество строк кода не имеет ничего общего с эффективностью.
Отсюда следует, что главный принцип не «не навреди», а «реши, зачем меряешь», или, на шаг веперед, «определи, какие решения хочешь принимать».
На мой взгляд — индивидуальные метрики в разработке вообще мало осмыслены. Только групповые. Например, безбажность кода применима не к программисту лично а к связке программист+тестер, так как с точки зрения управления не сделаная ошибка или исправленная — одно и то же, если на это ушло одинаковое количество времени (в этом примере я упрощаю).