Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 174
Проблема этой (в общем-то, правильной) статьи в том, что она делит людей строго на две группы, забывая, что есть третья — те, кто сел вылизывать правильный процесс, но не только не успел сделать этого к сроку, но и не успел два срока спустя, в результате чего никакого результата нет вообще.
Баланс нужен во всем.
Баланс нужен во всем.
Есть еще четвертая категория.
Тот кто посмотрел на это дело в древнерусской тоске и уволился к чертям собачьим.
Манагеры они на 97,58% жертвы принципа Питера.
Почему 97,58%? Да потому что так умнее выглядит. Иначе не поймут.
Тот кто посмотрел на это дело в древнерусской тоске и уволился к чертям собачьим.
Манагеры они на 97,58% жертвы принципа Питера.
Почему 97,58%? Да потому что так умнее выглядит. Иначе не поймут.
IMHO те, кто вылизывает вылизанный процесс и не укладываются в сроки, не имеют руководителей, ведь кому кроме как руководителю принимать решение и следить за протекаемыми процессами?
Опять же, легко спихнуть все на работника — мол сам так решил.
Верно — организовать процесс и отследить его.
Опять же, легко спихнуть все на работника — мол сам так решил.
Верно — организовать процесс и отследить его.
«Отслеживание» стоит слишком много ресурсов. Все-таки, весь смысл правильно поставленных процессов в том, чтобы делегирование обязанностей происходило легче.
Но вообще, надо отметить, что в статье оба «примера» принимают решение самостоятельно. Если бы там был руководитель, дело бы пошло иначе.
Но вообще, надо отметить, что в статье оба «примера» принимают решение самостоятельно. Если бы там был руководитель, дело бы пошло иначе.
Особенно классно руководители делают так:
— создай на себя задачу (в багтрекере) по этой проблеме
— создай на себя задачу (в багтрекере) по этой проблеме
Если процесс построен и выполняется хреново, то и результат будет таким же. Рано или поздно. В IT или в сексе :)
>> Если шустрый эникейщик быстро пробегает, устанавливая в заданный срок программу на все ПК, это неправильно. Пусть осваивают методы деплоинга приложений в интросети.
Как только эникейщик освоит методы деплоя, он найдет себе другую работу, с зарплатой в два раза больше, и мне придется искать и, главное, обучать, нового эникейщика, что связанно с весьма немалыми рисками. Так что пусть уж бегает, на мой век хватит, все равно через пол года я пойду на другое место и будущая проблема будет уже не моей проблемой :)
Как только эникейщик освоит методы деплоя, он найдет себе другую работу, с зарплатой в два раза больше, и мне придется искать и, главное, обучать, нового эникейщика, что связанно с весьма немалыми рисками. Так что пусть уж бегает, на мой век хватит, все равно через пол года я пойду на другое место и будущая проблема будет уже не моей проблемой :)
Россия — щедрая душа.
И что в этом плохого? Уйдет один, придет другой. Если Вы контора правильная: коллектив грамотный, задачи не в ущерб личной жизни и деньги платите не жмотясь, а как того заслуживает спец, то от Вас не только убегать не будут, все будет с точностью наоборот, к Вам бегать будут!
Деньги плачу не я, а хозяин бизнеса. А возиться с эникещиками — мне. Пока их обучишь — они наломают немало дров, а потом все равно уйдут, потому что хозяин платить больше не желает. Так чего мне переживать за его бизнес? Пусть «экономит». Самое же печальное то, что мне такой подход категорически не нравится, но я понимаю, что он оправдан. Хозяин урывает деньги здесь и сейчас, он не смотрит в будущее просто потому, что нет уверенности, что завтра его бизнес не отнимут (увы, это реалии Украины, уж не знаю как у вас в России). Так зачем вкладываться, если вася все сделает здесь и сейчас за пол цены? Более того, конкурентноспособность хозяина напрямую зависит от благосклонности чиновников, а не от умения васи хорошо делать свое дело. Вот это все очень печально.
В таком случае статья адресована не Вам, а хозяину бизнеса (ну, или кто там принимает решения).
А никто не принимает решения.
Ни чиновники, ни Вася, ни хозяин бизнеса…
Машина крутится. Всех всё устраивает.
Сегодня утром с таксистом дискутировали на эту тему)
Даже хозяин бизнеса (что уж говорить о начальнике госструктуры) временьщик которому нужно урвать иначе фейл.
Здесь никто не решает. Статья интересная но лишь для общего развития. Красивое художественное оформление известных всем и очевидных истин.
Такая же сферическая вещь как и то с чем она призвана бороться.
На самом деле в реальности чуть более чем всегда это невозможно будет исправить.
Сколько я видел процедур, даже руководств по управлению качеством и прочего, прочего никоим образом не связанных с реальностью…
Стопитсот раз видел как человек с системным подходом оказавшись в авральном окружении превращается в пожарника и «быдлокодера». Даже руководитель.
Ни чиновники, ни Вася, ни хозяин бизнеса…
Машина крутится. Всех всё устраивает.
Сегодня утром с таксистом дискутировали на эту тему)
Даже хозяин бизнеса (что уж говорить о начальнике госструктуры) временьщик которому нужно урвать иначе фейл.
Здесь никто не решает. Статья интересная но лишь для общего развития. Красивое художественное оформление известных всем и очевидных истин.
Такая же сферическая вещь как и то с чем она призвана бороться.
На самом деле в реальности чуть более чем всегда это невозможно будет исправить.
Сколько я видел процедур, даже руководств по управлению качеством и прочего, прочего никоим образом не связанных с реальностью…
Стопитсот раз видел как человек с системным подходом оказавшись в авральном окружении превращается в пожарника и «быдлокодера». Даже руководитель.
Еще раз, для особо одаренных: хозяин бизнеса не сует свой нос в мелкие дела, ему нужно одно — быстро и дешево!
Похоже нам с вами разные «хозяева бизнеса» попадались :)
Если не считать таких «бизнесменов» как «у меня свой лоток на рынке» и тех кто просто украл бизнес или денег, то все мои знакомые в первую очередь думают о том, чтобы не потерять свои инвестиции. Быстро и дешево это уже нонсенс, и как правило такой нонсенс это или наемный руководитель или тот кто за чужие деньги «мутит».
Хозяину нужно «максимум ROI при минимуме рисков», а не тупо «чем больше урвать тем лучше».
И лишь потому что в совке долгосрочные инвестиции убыточны появляется рвачество. Но это не причина а лишь следствие безопасности…
Ну и да, есть такое, что большинство даже настоящих руководителей элементарно не умеют оценивать риски.
Но если предлагаешь список вариантов с описанием рисков, то чаще всего деньги отходят на второй план.
Если не считать таких «бизнесменов» как «у меня свой лоток на рынке» и тех кто просто украл бизнес или денег, то все мои знакомые в первую очередь думают о том, чтобы не потерять свои инвестиции. Быстро и дешево это уже нонсенс, и как правило такой нонсенс это или наемный руководитель или тот кто за чужие деньги «мутит».
Хозяину нужно «максимум ROI при минимуме рисков», а не тупо «чем больше урвать тем лучше».
И лишь потому что в совке долгосрочные инвестиции убыточны появляется рвачество. Но это не причина а лишь следствие безопасности…
Ну и да, есть такое, что большинство даже настоящих руководителей элементарно не умеют оценивать риски.
Но если предлагаешь список вариантов с описанием рисков, то чаще всего деньги отходят на второй план.
В СССР долгосрочные инвестиции предполагали окупаемость в 7-10 лет в зависимости от отрасли. Поэтому убыточными они никак быть не могли. Рвачество — это вообще-то примета нашего времени, которое вы непонятно почему называете «совком».
Я не время называю, а территорию… Украина, Россия и т.п.
Не во времени дело.
Дело в людях.
В людях тоже преимущественно рвачество… чтобы вырастить человека нужны долгосрочные инвестиции… Да и то без гарантии возвращения этих инвестиций. И я не про деньги сейчас…
Гораздо проще дать некую базовую подготовку, и в бой…
Та же демократия к примеру. Кто учил этих людей демократии? Есть у них хоть какая-то база? Ведь нет…
Лично у меня есть более менее понимание того как она устроена… изучал, опыты ставил на небольших коллективах и все такое… но вот у основной массы? есть хоть какой-то базис? Нет его…
Права дали, обязанности дали. Что с ними делать не рассказали.
В советское время и то больше этого всего было. Даже тот же комсомол…
И не надо мне говорить что это все не то, и мол «там» тоже ничему не учат.
Я всегда в таких спорах вспоминаю фразу одной моей подруги получившей образование в Европе:
"Когда я баллотировалась на президента университета, мой друг мне посоветовал...."
Не важно уж, что он ей посоветовал… банальную вещь понятную всем образованным людям, и невероятную для подавляющего большинства политиков… Важно что люди знают как устроена система.
Не во времени дело.
Дело в людях.
В людях тоже преимущественно рвачество… чтобы вырастить человека нужны долгосрочные инвестиции… Да и то без гарантии возвращения этих инвестиций. И я не про деньги сейчас…
Гораздо проще дать некую базовую подготовку, и в бой…
Та же демократия к примеру. Кто учил этих людей демократии? Есть у них хоть какая-то база? Ведь нет…
Лично у меня есть более менее понимание того как она устроена… изучал, опыты ставил на небольших коллективах и все такое… но вот у основной массы? есть хоть какой-то базис? Нет его…
Права дали, обязанности дали. Что с ними делать не рассказали.
В советское время и то больше этого всего было. Даже тот же комсомол…
И не надо мне говорить что это все не то, и мол «там» тоже ничему не учат.
Я всегда в таких спорах вспоминаю фразу одной моей подруги получившей образование в Европе:
"Когда я баллотировалась на президента университета, мой друг мне посоветовал...."
Не важно уж, что он ей посоветовал… банальную вещь понятную всем образованным людям, и невероятную для подавляющего большинства политиков… Важно что люди знают как устроена система.
Вы с Марса прилетели? Какие к черту «оценивать риски»??? Вы себе какую угодно бизнес-схему идеальную нарисуйте, продумайте инвестиции, а завтра к вам придут из мерии и попросят поделится. Ах вы не включили в свой бизнес-план «гуманитарную помощь» и делиться не хотите? Ну что же, хорошо, до свидания. А на завтра в офис приезжают люди в масках с автоматами и вывозят все сервера. Вообще все, успел ли вася установить на них что-то или нет. И это далеко не лоточный бизнес. Если вы живете в Украине, то 1 к 2 что у вас в квартире есть продукция, произведенная холдингом. И вот такой далеко не мелкий хозяин просто не желает инвестировать. Потому что он не знает, что будет через год. Зачем ему вкладываться, если через месяц может придется расставаться со всем добром? Вот и работают он и ему подобные с васями. И самое невероятное — это то, что даже при таком подходе что-то да получается сделать, предприятие работает, не разваливается!
Вы видимо принципиально не хотите читать то, что вам пишут, а живете именно в своем выдуманном мире.
Политические риски это тоже риски :)
Я лишь сказал о том, что «реальные пацаны» мыслят чуть другими категориями.
Я и сам попадал под маски-шоу, как в качестве директора, так и в качестве наемного работника.
И моя фирма в свое время выиграла тендер для одного холдинга в вопросах информационной безопасности именно благодаря тому, что в нашем предложении были некоторые рекомендации по поведению в условиях маски-шоу. И речь шла далеко не о банальных решениях типа Кольчуги.
Политические риски это тоже риски :)
Я лишь сказал о том, что «реальные пацаны» мыслят чуть другими категориями.
Я и сам попадал под маски-шоу, как в качестве директора, так и в качестве наемного работника.
И моя фирма в свое время выиграла тендер для одного холдинга в вопросах информационной безопасности именно благодаря тому, что в нашем предложении были некоторые рекомендации по поведению в условиях маски-шоу. И речь шла далеко не о банальных решениях типа Кольчуги.
Как владелец бизнеса в Украине, при чем с рисками выше среднего по рынку, скажу что ваш «владелец бизнеса» обычный рвач или трус или дурак. Риски того, что все рухнет из-за кривой инфраструктуры на порядок выше этих всех «отберут бизнес».
«Все рухнет»? Какие громкие слова. Что рухнет? За один день не поставят в удаленном офисе десяток рабочих мест? Ну так завтра поставят, ай-яй-яй, подумаешь, большая беда. Машины с материалом из-за непогоды задержались — вот это гораздо важней того, то десяток бухгалтеров поработают с бумажками, а в базу вобьют после работы или в субботу-воскресенье. В крайнем случае наймут еще оного васю, будут они вдвоем бегать. Все равно дешевле выйдет.
Ну рухнет, допустим, не бизнес глобально, а сорвутся некие сделки из-за которых с таким бизнесом не захотят иметь дела вменяемые партнеры/заказчики и он будет болтаться как говно в проруби, пока в один прекрасный момент не пойдет ко дну из-за превышения расходами доходов.
Отмазка «завтра придут и заберут» гниловата. Человек просто привык жить одним днем, потому и живет и бизнес строит по тем-же принципам. Тот, кто хочет строить нормально, строит, в том числе и в Украине. Не нужно напускать жути, рассказывая как тут все ужасно и рисково. По крайней мере, не надо об этом говорить тем, кто сам в теме и этим занимается.
Шарашки есть в любых странах. Потому такой подход у руководителя этих шарашек. У славянских народов распиздяйство в крови уже, потому тут их больше.
Отмазка «завтра придут и заберут» гниловата. Человек просто привык жить одним днем, потому и живет и бизнес строит по тем-же принципам. Тот, кто хочет строить нормально, строит, в том числе и в Украине. Не нужно напускать жути, рассказывая как тут все ужасно и рисково. По крайней мере, не надо об этом говорить тем, кто сам в теме и этим занимается.
Шарашки есть в любых странах. Потому такой подход у руководителя этих шарашек. У славянских народов распиздяйство в крови уже, потому тут их больше.
Именно «привык жить одним днем». Поэтому у него все «работают на результат». Именно так, как описано в статье: сделать здесь и сейчас, любым способом, а дальше хоть трава не расти. Удивительно, но такая ситуация длится уже полтора десятка лет. Видать, минусы от отсутствия долгосрочных инвестиций компенсируются простотой и дешевизной сиюминутных решений. Так что подход «работать на результат» в том негативном виде, описанном в статье, тоже имеет право на жизнь.
Ну есть например такой кейс как увод базы. Как клиентов так и поставщиков.
Полная неготовность к нападению государства или рейдеров.
Да мало ли что еще может быть…
В свое время хорошо изучил один случай когда увод базы привел к закрытию фирмы.
Там правда нюанс был в том, что постоянные расходы составляли более 90% расходов компании, так что потеря 30% клиентуры вывела фирму за грань рентабельности, но это не единственный случай когда маленькая ошибка приводит к большой заднице.
Полная неготовность к нападению государства или рейдеров.
Да мало ли что еще может быть…
В свое время хорошо изучил один случай когда увод базы привел к закрытию фирмы.
Там правда нюанс был в том, что постоянные расходы составляли более 90% расходов компании, так что потеря 30% клиентуры вывела фирму за грань рентабельности, но это не единственный случай когда маленькая ошибка приводит к большой заднице.
Виталий, как я могу с Вами связаться?
Айнур, основатель Lingualeo, +79257905580
Вот хороший исторический пример работы на результат: Рязанское чудо.
К сожалению, есть признаки того, что нечто подобное сейчас происходит в масштабах страны, причём не только в IT-сфере.
К сожалению, есть признаки того, что нечто подобное сейчас происходит в масштабах страны, причём не только в IT-сфере.
Мысль в целом возможно и правильная, но доказывать ее на выдуманных примерах — крайне неправильно. Я могу придумать примеры, где 100 раз из 100 были правы те, кто делали как попало.
Более того, все в вашим примере ориентировались на результат, первые на локальный, вторые на глобальный.
Что касается самой темы, с точки зрения программирования, хочу добавить несколько слов:
Основной критерий качества программного продукта — его работоспособность, но далеко не единственный. И тем, кто в ответ на критику кода говорит, что он же работает, следует напоминать, что модернизация этого кода будет дорогой, исправление ошибок — дорогим, период адаптации к коду — долгим.
Более того, все в вашим примере ориентировались на результат, первые на локальный, вторые на глобальный.
Что касается самой темы, с точки зрения программирования, хочу добавить несколько слов:
Основной критерий качества программного продукта — его работоспособность, но далеко не единственный. И тем, кто в ответ на критику кода говорит, что он же работает, следует напоминать, что модернизация этого кода будет дорогой, исправление ошибок — дорогим, период адаптации к коду — долгим.
В том то и дело, что несферический эникейщик не стал бы играться с инсталятором если бы ориентировался на результат. Ему просто было интересно сделать это ПРАВИЛЬНО. :)
у несферического эникейщика — его «правильно» может отличаться от «правильности» другого специалиста. так что оценить «правильность» принятого решения (пути) — может только квалифицированный специалист.
В примерах из статьи — оценить методы решения проблемы должен какой-то технический директор. А нет его — о чем тогда вообще говорить? Тогда пусть себе «работают на результат», там и без подобного хватит проблем.
В примерах из статьи — оценить методы решения проблемы должен какой-то технический директор. А нет его — о чем тогда вообще говорить? Тогда пусть себе «работают на результат», там и без подобного хватит проблем.
Все совершенно правильно написали про процесс. Рад, что в России есть люди, которые так же думают.
Приведу свой пример — на складе начали приемку товара, думая, что процесс пропишут потом.
Через два месяца, когда товар уже лежал, пригласили специалиста по качеству прописывать процессы.
Что было дальше — очевидно :) Склад заполнен не так, как нужно, люди не обучены, стандарты не соблюдаются.
Короче — учите ISO 9001, прописывайте процессы по нему (внедряйте СМК) и будет вам счастье.
Приведу свой пример — на складе начали приемку товара, думая, что процесс пропишут потом.
Через два месяца, когда товар уже лежал, пригласили специалиста по качеству прописывать процессы.
Что было дальше — очевидно :) Склад заполнен не так, как нужно, люди не обучены, стандарты не соблюдаются.
Короче — учите ISO 9001, прописывайте процессы по нему (внедряйте СМК) и будет вам счастье.
Автор все правильно пишет про бомбу замедленного действия и про то, что если делать, то желательно сразу правильно (вернее, делать «в локальном экстремуме»).
Да вот только автор так и не понял, что значит «ориентированность на результат» (ОНР).
ОНР — это всего лишь способность человека делать то, что он сам обещал/планировал себе, пусть даже и с незначительным опазданием. ОНР — это когда с человеком заказчик задачи говорит всего дважды: когда обсуждают задачу и когда смотрят результат (и не требуется никакой пуш, никаких «ну как там?» и дополнительных «когда будет готово?»). ОНР — это когда человек, в процессе работы над задачей вдруг понявший, что чего-то не понимает/не хватает информации, не сидит сиднем до конца итерации, а идет к заказчику и проясняет все свои сомнения. ОНР — это человке, на которого можно положиться в трудную минуту.
Качество результата не имеет к ОНР никакого отношения. Качество результата имеет отношение только к размеру интеллекта человека, а у кого размер интеллекта недостаточен для выполнения задач, очевидно, не должен над ними работать.
Да вот только автор так и не понял, что значит «ориентированность на результат» (ОНР).
ОНР — это всего лишь способность человека делать то, что он сам обещал/планировал себе, пусть даже и с незначительным опазданием. ОНР — это когда с человеком заказчик задачи говорит всего дважды: когда обсуждают задачу и когда смотрят результат (и не требуется никакой пуш, никаких «ну как там?» и дополнительных «когда будет готово?»). ОНР — это когда человек, в процессе работы над задачей вдруг понявший, что чего-то не понимает/не хватает информации, не сидит сиднем до конца итерации, а идет к заказчику и проясняет все свои сомнения. ОНР — это человке, на которого можно положиться в трудную минуту.
Качество результата не имеет к ОНР никакого отношения. Качество результата имеет отношение только к размеру интеллекта человека, а у кого размер интеллекта недостаточен для выполнения задач, очевидно, не должен над ними работать.
В общем, это такой идеальный человек, который полностью растворяется в заказчике. Ну что-то типа японской жены.
Знаете, у меня вот не такой опыт управления большой, может, но уже сейчас одно ясно.
Без контроля, постоянной обратной связи НИЧЕГО не работает. Вообще.
Как верно в статье заметили, люди стремятся минимизировать энергетические расходы на любые действия. А если нет контроля — нет и энергетических затрат, зато они есть в режиме аврала и есть просранные сроки.
Да, есть 5%, группа А по Уэлчу, но про них не пишут такие статьи.
Без контроля, постоянной обратной связи НИЧЕГО не работает. Вообще.
Как верно в статье заметили, люди стремятся минимизировать энергетические расходы на любые действия. А если нет контроля — нет и энергетических затрат, зато они есть в режиме аврала и есть просранные сроки.
Да, есть 5%, группа А по Уэлчу, но про них не пишут такие статьи.
Верно. Обратная связь в любом деле очень важна, «работа в стол» или создание того, что потом не будет нужно ни заказчику, ни пользователям — проигрышный вариант. Поэтому проджект-менеджмент (настоящий) — это серьезная и важная работа, даже для ОНР-сотрудников (ведь зачастую пользователей еще просто нет, и ПМ — единственный человек, который может мотивировать делать новую фичу). Обратная связь — вот что важно. Не контроль, а именно обратная связь, вовлеченность, адекватность.
Но у одного приходится каждую минуту стоять над душой и все время быть недовольным результатом, а у другого — возникает ощущение надежности и уверенности. Это второе и есть ОНР. Люди, которые пишут в вакансии ОНР, просто хотят уверенности в сотруднике.
Но у одного приходится каждую минуту стоять над душой и все время быть недовольным результатом, а у другого — возникает ощущение надежности и уверенности. Это второе и есть ОНР. Люди, которые пишут в вакансии ОНР, просто хотят уверенности в сотруднике.
Как было в «Как пасти котов»: Получаешь не то, что ожидаешь, а то, что контролируешь
лезущий своими мерзкими щупальцами в нежное лоно базы.
Да, такой «Базы Данных» я ещё не представлял. )
Хорошо что все закончилось отлично и база данных съела осьминога (GodClass).
Судя по действиям некоторых БД-шников, они свои базы видят именно такими ;)
Это же БДСМ-щики!
Всегда думал что «мускуль» это мужик, ан нет, смотрим на грудь БД. )
P.S. Картинки шикарные, с контекстом, гармонично вписанные в текст.
P.S. Картинки шикарные, с контекстом, гармонично вписанные в текст.
Хоть статья и перенасыщена эмоциями, я соглашусь с тем, что борьба за результат (клиента, контракт, галочку и т.д.) в ущерб процессу — это порочная практика.
Задача менеджера в данном случае состоит, на мой взгляд, в том, чтобы суметь оптимизировать существующие процессы так, чтобы следуя им, можно было достичь результата в срок. То есть подогнать процессы, учитывая риски (поломать, недоглядеть и т.д.) и добиться результата. И самое главное, после достижения оного — провести пост-мортем ревью, а именно «подбить бабки», понять, что было правильно, что нет. Подвести итоги и учесть их на будущее.
Без этого «итогового» этапа все изменения в процессах или просто достижение результата, обходя процессы — все это рано или поздно приведет к катастрофе, локального или глобального масштаба.
Задача менеджера в данном случае состоит, на мой взгляд, в том, чтобы суметь оптимизировать существующие процессы так, чтобы следуя им, можно было достичь результата в срок. То есть подогнать процессы, учитывая риски (поломать, недоглядеть и т.д.) и добиться результата. И самое главное, после достижения оного — провести пост-мортем ревью, а именно «подбить бабки», понять, что было правильно, что нет. Подвести итоги и учесть их на будущее.
Без этого «итогового» этапа все изменения в процессах или просто достижение результата, обходя процессы — все это рано или поздно приведет к катастрофе, локального или глобального масштаба.
Прекрасно написанный текст. Браво! По сути: то, о чем вы говорите описано в CMMI . Переход от людей, которые делают проект, к процессам, а потом к контролируемым улучшениям процессов. Правда, в некоторых конторах CMMI level 5 превращается в «процесс ради процесса», и иконку у приложения меняют 3 месяца.
Статья хорошая и правильная, но хотелось добавить, что лозунг «Работа на результат» вероятнее всего противопоставлял рабоче-крестьянский труд, четко ориентированный на результат, труду разного рода бюрократов, ориентированный исключительно на процесспросиживания рабочего времени с целью получить за это денежку, совершенно не имея мотивации. И, конечно, сейчас эта фраза употребляется всего лишь для красного словца.
Не рассмотрен ещё один вариант, когда человек ориентирован на зарплату. Такой, вроде бы, антипод ОНР, но ещё страшнее и опаснее. Монотонно и не торопясь ваяет неведомую хрень вопреки вяскому здравому смыслу, пичкая багами и недокументированным функционалом, чтобы наверняка было чем ещё занятся в ближайшие месяцы и чтоб уж точно не уволили. А как такого уволить, если только он знает, где в этой куче го#на найти и исправить проблему.
я лично чаще сталкивался не с «монотонно и не торопясь ваяет», а с «все ресурсы бросаем на %фичу% и запиливаем быстро», в результате оного получается еще более неведомая херня, содержащая процедурную часть код в нескольких экземплярах (по числу приложивших руку), падающая регулярно, но зато у всех есть работа — у программистов, у тестеров и даже начальник ходит довольный, считая себя важной шишкой (ведь у него столько подчиненных!)
Refactoring. Итерации. Результат.
Refactoring. Итерации. Результат.
Refactoring. Итерации. Результат.
…
повторить до выздоровления
Refactoring. Итерации. Результат.
Refactoring. Итерации. Результат.
…
повторить до выздоровления
быдлокодить тоже можно красиво… нужен костыль? организовал класс, функцию. прокомментировал ее… и в отдельную папочку положил… вызвал красиво…
Работая в вебстудии, когда все менеджеры получали % с продаж и чем скорее тем лучше, все мои попытки как то все структурировать провалились… как там… «дубась код»
Работая в вебстудии, когда все менеджеры получали % с продаж и чем скорее тем лучше, все мои попытки как то все структурировать провалились… как там… «дубась код»
>которые если что-то и пишут, то делают это раз и навсегда, чтобы это что-то работало при любых условиях
вы должны делать масштабируемо и быстро. это не противоречит классическому треугольнику быстро, дешево, качественно.
для этого нужно развивать профессионализм, и делать это постоянно. вот обучение и развитие — это процесс, а результатом является ваша ЗП (не берем чинуш и тд)
любых условий НЕТ. раз и навсегда НЕТ. вышла новая версия системы, или вообще все пересели на линукс — дотнет прога идет нахер, ее надо портировать. компы завтра будут биологические — вообще все может поменяться.
вы должны делать масштабируемо и быстро. это не противоречит классическому треугольнику быстро, дешево, качественно.
для этого нужно развивать профессионализм, и делать это постоянно. вот обучение и развитие — это процесс, а результатом является ваша ЗП (не берем чинуш и тд)
любых условий НЕТ. раз и навсегда НЕТ. вышла новая версия системы, или вообще все пересели на линукс — дотнет прога идет нахер, ее надо портировать. компы завтра будут биологические — вообще все может поменяться.
Почему автор статьи узнаётся по стилю иллюстраций?..
Мысли-то верные, но действительно сейчас никто не вкладывает в эту фразу, ничего больше, чем: «На выходе мы хотим получить классный продукт». Да и вообще люди употребляют достаточно много слов, фраз, идиом не сильно вникая в их семантику. Говорят так, просто потому что когда-то услышали это от Васи Пупкина, и это так круто прозвучало, что они вооружились этой фразой до конца своих дней.
В данном случае первые поняли задачи как «быстро поставить софт»\«быстро сделать импорт вот этой таблицы в систему», вторые соответственно по-своему. То, что менеджер не знал, что ему конкретно нужно и не посоветовался(раз уж не знал сам) со знающими людьми, его косяк.
Чтобы лучше понять важность четкого ТЗ, представьте себе ситуацию, когда нужно единожды на 2 машины установить какое-то приложение, менеджер так же скажет «нужно установить приложение» и эти же двое будут идти описанными в статье методами.
Чтобы лучше понять важность четкого ТЗ, представьте себе ситуацию, когда нужно единожды на 2 машины установить какое-то приложение, менеджер так же скажет «нужно установить приложение» и эти же двое будут идти описанными в статье методами.
Вопрос в том, что такое «результат» — что в него включается… Боюсь, у вас и у хозяев конторы представления о границах (во времени и в пространстве) результата разные.
В принципе, последствия «говноадминства» лечатся регулярными бэкапами. Не ставится новая версия поверх старой? Поставить из бэкапа систему без старой версии.
Насчёт КИС — так разработчикам КИС надо писать инструкции по установке новых версий поверх старых…
В случае Андрея и Евгения контора получила результат, адекватный её уровню. Вы не задумывались о том, что деньги на внешнего программиста таки легко нашлись, и контора из-за этого не лопнула? Небось ещё начальник Евгения отпилил с этих денег, чего в случае с Антоном он был лишён. А Антон подставил начальника, одобрившего методику Евгения, что ему, в общем, с рук просто так не сойдёт…
В принципе, последствия «говноадминства» лечатся регулярными бэкапами. Не ставится новая версия поверх старой? Поставить из бэкапа систему без старой версии.
Насчёт КИС — так разработчикам КИС надо писать инструкции по установке новых версий поверх старых…
В случае Андрея и Евгения контора получила результат, адекватный её уровню. Вы не задумывались о том, что деньги на внешнего программиста таки легко нашлись, и контора из-за этого не лопнула? Небось ещё начальник Евгения отпилил с этих денег, чего в случае с Антоном он был лишён. А Антон подставил начальника, одобрившего методику Евгения, что ему, в общем, с рук просто так не сойдёт…
Хорошие примеры, плохо только, что выдуманные :)
Давайте я выдумаю другой пример:
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
:)
Давайте я выдумаю другой пример:
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
:)
Примерно так, а качество «быстрого результата» со временем может улучшатся через рефакторинги.
Многие программисты свято уверены, что лучше выпустить вылизанный и идеальный продукт, но «когда-то», чем пусть не идеальный, но решающий свою основную задачу сейчас. Но зачастую когда наступает «когда-то», то их продукт уже никому не нужен. Супер стабильность у куча всяких фич не являются залогом успеха.
Это в идеальном мире. А в реальном — всех клиентов и все деньги получает тот, кто успел первым.
Васины клиенты рекомендуют Васю дальше. Вася в гугле на первой странице. К васиной программе разрабатывают кряки и плагины. Совместимость с васиной программой закладывают в ТЗ к другим продуктам. У Васи толпа фанатов и ненавистников. На Васю работает уже десяток толковых программистов и один неплохой дизайнер. И, да, Вася постоянно улучшает свою программу, еженедельно выпускает патчи, прислушивается к мнению клиентов, так что его программа хоть и далеко не идеальна, но достаточно хороша, чтобы ею пользоваться и не переходить на конкурентный продукт, который, к тому же, тоже стоит денег.
Петину программу никто не знает, кроме некоторых эстетствующих гиков.
Васины клиенты рекомендуют Васю дальше. Вася в гугле на первой странице. К васиной программе разрабатывают кряки и плагины. Совместимость с васиной программой закладывают в ТЗ к другим продуктам. У Васи толпа фанатов и ненавистников. На Васю работает уже десяток толковых программистов и один неплохой дизайнер. И, да, Вася постоянно улучшает свою программу, еженедельно выпускает патчи, прислушивается к мнению клиентов, так что его программа хоть и далеко не идеальна, но достаточно хороша, чтобы ею пользоваться и не переходить на конкурентный продукт, который, к тому же, тоже стоит денег.
Петину программу никто не знает, кроме некоторых эстетствующих гиков.
Ваше утверждение отстало как минимум лет на десять. Оно бы еще хоть как-то было бы правдоподобно в те времена когда фраза «Сервер работает под операционной системой Windows» еще было анекдотом.
Вот на таких камментах мы, романтики, и палимся. :)
В идеальном мире должно быть именно так, как Вы описали. Но в реальном я такого ещё ни разу не встречал. К сожалению.
В идеальном мире должно быть именно так, как Вы описали. Но в реальном я такого ещё ни разу не встречал. К сожалению.
Да, именно так обычно и бывает. На истории развития программирования это очень заметно. Когда-то был простенький движок СУБД, который вообще кроме insert/delete/update/select по ключу ничего не умел. Но слишком многие (не имеющие никакого представления о СУБД вообще) выбирали его с целью запилить что-то небольшое прямо сейчас, в итоге получился нынешний mysql. Куда более изначально продуманный postgresql прилично отстает в популярности.
Аналогично с HTML вышло — были всякие интересные способы написания распределенных приложений, но победило web-программирование. А все потому, что там сложно было, а CGI-скрипт можно было за 10 минут написать с минимальным опытом, и пофиг все остальное.
А помните все эти продуманные протоколы вроде CORBA/SOAP?
Фактически все развитие ИТ убеждает нас в том, что обычно побеждает самая кривая и примитивная технология, которая потом годами допиливается до минимально-вменяемого состояния. Так происходит потому, что популярность технологии обеспечивает масса новичков, которая имеет (на тот момент) самые простые запросы, ищет самое простое решение, которое потом растет вместе с ростом запросов тех самых новичков.
А потом вырастает новое поколение программистов, смотрит на получившегося монстрика и начинает на коленке опять писать очередное «простое решение».
Аналогично с HTML вышло — были всякие интересные способы написания распределенных приложений, но победило web-программирование. А все потому, что там сложно было, а CGI-скрипт можно было за 10 минут написать с минимальным опытом, и пофиг все остальное.
А помните все эти продуманные протоколы вроде CORBA/SOAP?
Фактически все развитие ИТ убеждает нас в том, что обычно побеждает самая кривая и примитивная технология, которая потом годами допиливается до минимально-вменяемого состояния. Так происходит потому, что популярность технологии обеспечивает масса новичков, которая имеет (на тот момент) самые простые запросы, ищет самое простое решение, которое потом растет вместе с ростом запросов тех самых новичков.
А потом вырастает новое поколение программистов, смотрит на получившегося монстрика и начинает на коленке опять писать очередное «простое решение».
А помните все эти продуманные протоколы вроде CORBA/SOAP?
А что SOAP? Он-то прекрасно живет и здравствует, один из индустриальных стандартов де-факто.
1) SOAP постепенно вытесняется REST-ом
2) CORBA таки не сильно популярна.
2) CORBA таки не сильно популярна.
1) Каким таким образом архитектура вытесняет протокол?
SOAP постепенно вытесняется REST-ом
Во-первых, это не противоречащие вещи. А во-вторых, где вытесняется? Я вот что-то не вижу пока смерти SOAP в, скажем, интеграционных решениях.
CORBA таки не сильно популярна.
А про нее я изначально ничего не говорил.
В общем, спасибо автору, прояснил, что фраза об «ориентированности на результат» — сделаное на основе тавтологии маркетинговое нае.алово (типа «новейшая секретная технология 'думание мозгами, а не попой'») из серии приёмов «ниже пояса».
А что на этой картинке сделали с бедным осьминожкой — кислоты в аквариум налили?
Проверяя задачи студентов по программированию, порой замечаю удивительную вещь. Есть класс студентов, которые способны в точности выполнить все требования программы, но при этом на неё смотреть противно. А формально не к чему придраться. Другие наоборот, могут иметь формальные недочёты, на которые очень хочется закрыть глаза, потому что в целом программа просто хороша. Кажется, сейчас я понимаю, кто вырастет из тех и других студентов.
Статья написано отлично, только один нюанс: Евгений и Павел — квалифицированные специалисты, а Андрей и Антон — просто эникей (не в обиду, да.). И они все работали на результат. (Мнение не навязывается)
Или я слишком однобоко смотрю?
Или я слишком однобоко смотрю?
Слишком. И тех, и других сложно назвать квалифицированными, если воспринимать текст буквально. Ни те, ни другие не рассмотрели альтернативы, не оценили плюсы и минусы в каждом подходе, а вторые ещё и сроки запороли. Никто из четверых не подошел к начальнику и не сказал: «вот есть такой вариант, а есть такой, первый точно в срок уложимся, но это бомба замедленного действия, а со вторым есть риск не уложиться в срок, если я слишком оптимистично оцениваю возможные подводные камни в незнакомой мне пока технологии. Ты начальник — ты решай, информацию я предоставил, что для фирмы критично я не знаю».
Почему те, кто сделал работу так, что в итоге на второй раз всё развалилось — более «квалифицированные специалисты». «Квалифицированные специалисты» в качестве рядовых исполнителей, чётко не лезущих за пределы ограниченной им компетенции? Типа «если начальство одобрило делать плохо, не надо пытаться делать хорошо»?
Мне кажется, передергиваний в статье очень много. Можно привести большое количество примеров, когда именно «грязный хак» и/или «силовое» получение результата — единственное спасение. Перепрыгивание пропасти на 100%, а не на 99%. В этих ситуациях не нужен некий идеальный результат, нужен good enough результат, но в срок, ибо по истечению срока уже вообще никакой результат не нужен.
Исходя из разбора автором статьи двух ситуаций можно сделать вывод, что некомпетентно задачи были поставлены.
Единичные задачи и получение единичных результатов (в условиях бизнес-процессов данной компании) можно делать и не сильно заморачиваясь процессной составляющей. Если получение подобных/похожих результатов планируется и/или возможно в дальнейшем, то на процессную составляющую необходимо обращать внимание. Можно вспомнить притчу про дровосеков и затачивание топора. В противном случае трудозатраты не окупятся.
В этих двух примерах задачи были поставлены как «единичные», а на самом деле (судя по разбору ситуаций) это были «процессные» задачи.
Исходя из разбора автором статьи двух ситуаций можно сделать вывод, что некомпетентно задачи были поставлены.
Единичные задачи и получение единичных результатов (в условиях бизнес-процессов данной компании) можно делать и не сильно заморачиваясь процессной составляющей. Если получение подобных/похожих результатов планируется и/или возможно в дальнейшем, то на процессную составляющую необходимо обращать внимание. Можно вспомнить притчу про дровосеков и затачивание топора. В противном случае трудозатраты не окупятся.
В этих двух примерах задачи были поставлены как «единичные», а на самом деле (судя по разбору ситуаций) это были «процессные» задачи.
У меня раздвоение личности. Я ЕвгеноАнтон. Утром я просыпаюсь как Антон, передо мной лежит ТЗ. Я продумываю структуру, интерфейс. Открываю чистый лист своего любимого редактора. Вдумчиво и не торопясь я творю. Все готово. Я доволен. Заказчик доволен. Я иду спать (месяца на 2). Но злые силы не дремлют… они «колдуют»
Просыпаюсь смотрю на свой код. я не узнаю его… на список изменений и поправок и чувствую как во мне просыпается Евгений. =)
Просыпаюсь смотрю на свой код. я не узнаю его… на список изменений и поправок и чувствую как во мне просыпается Евгений. =)
Хорошая статья. Пусть примеры в ней утрированны, отражают две крайности, но суть именно в критериях качества работы. Качество, категория с трудом осязаемая, и различимая на расстоянии (во времени) — для чего нужны KPI. Локальный фэйл может быть глобальным вином.
Но идея глубже. Взаимосвязь процесса и результата, явно не указано в статье я бы сказал, протекает по инструментарию. Владение и обладание инструментом стоит денег. В конечном итоге, для процессов (так же как и для проектов), всё упирается в треугольник «быстро-качественно (на несколько раз)-дешево — выберите любые два».
А уже хороший менеджер должен знать, где надо дешево, где быстро, а где качественно. Это всё зависит от бизнеса.
Но идея глубже. Взаимосвязь процесса и результата, явно не указано в статье я бы сказал, протекает по инструментарию. Владение и обладание инструментом стоит денег. В конечном итоге, для процессов (так же как и для проектов), всё упирается в треугольник «быстро-качественно (на несколько раз)-дешево — выберите любые два».
А уже хороший менеджер должен знать, где надо дешево, где быстро, а где качественно. Это всё зависит от бизнеса.
Статья очень занятная, но, по большому счету, делать все супер-правильно занимает много времени, а от этого страдает бизнес. Вы никому не нужны если ваш код не приносит $$$. К тому же, в начинающих компаниях часто меняется направление, и попросту вся мега архитектура будет не нужна к тому времени, когда вы ее доделаете. Я давно практикую метод «baby steps». Прикидываю заране куда будет двигаться проект, и просто строю архитектуру расширяемой. Наращивая проект. Все вначале не оптимально, но регулярные код ревью и рефакторы — это наше все. Результат важнее. Без результата компания перестанет работать.
Почему-то статья рассматривает ориентированность на результат как решение задачи «в лоб». Я же понимаю это как:
— умение отличить главное от второстепенного
— умение не зацикливаться на мелочах
— умение использовать все возможные ресурсы для решения проблемы
— отсутствие отмазок вроде «жду что-то от Васи». Как правило, достаточно просто пнуть Васю, чтобы дело сдвинулось с мертвой точки. И не говорите, что это работа менеджера.
— умение отличить главное от второстепенного
— умение не зацикливаться на мелочах
— умение использовать все возможные ресурсы для решения проблемы
— отсутствие отмазок вроде «жду что-то от Васи». Как правило, достаточно просто пнуть Васю, чтобы дело сдвинулось с мертвой точки. И не говорите, что это работа менеджера.
Очень интересный пост. В котором, однако, не затронут ряд весьма важных моментов.
В этом посте показано, как люди путают несколько вещей, а о чем-то просто не имеют представления.
Путают инструмент и его цели. Любая организация работы, подход к ней, методология имеет свои плюсы и минусы. И если слепо следовать, не думая головой, одним и тем же догмам — пользы не будет.
Конкретно, речь о методологии работы на результат. Слепо повторять «работай на результат», при этом не поломав голову над определением, что же есть результат, глупо и неразумно. Что приводит к плачевным последствиям, что хорошо показано в исходном посте.
Теперь идеологию. Дело в том, что само разделение на результат и процесс весьма условно. Все почему-то забывают, что это — взаимосвязанные вещи. К примеру, для улучшения процесса производства чего-либо нужна отрицательная обратная связь, сравнение получаемого результата с тем, что ожидается. И обратно, результат является следствием процесса, поэтому без настройки процесса результат меняться не будет.
На примере программиста и компании. Когда я спрашиваю у людей, что главнее — мозг, глаз или сердце по отдельности, ответа нет. Потому что человек — это нечто большее, чем органы, это работающая система. Так и фирма — это работающая система. В ней программист — это один из органов, связанных с другими. Если программист будет только заниматься процессом, не выдавая результат (вечный рефакторинг), то фирма ничего не продаст. В конечном итоге поток денег прекратится, и не станет ни фирмы, ни работы у программиста. Поэтому программисты не понимают часто задач бизнеса, а бизнес не понимает задач программиста, только если постоянно не объяснять, что, зачем и как.
Справедливости ради, если не заниматься внутренним процессом производства, то полученный быстрый результат может через год-другой из-за плохого года загубить компанию. Руководителей, которые не понимают, что программисту важны KISS, SOLID, нужные индексы и вообще правильная архитектура и тд, и не дают время на рефакторинг, можно отправить в биореактор. Как фрилансер в прошлом, видя тонны говнокода, где никто не рефакторил (не давали времени людям), говорю со всей ответственностью.
Далее, про представление. Указанные противоречия в прошлом абзаце, а также про масштабируемые системы и «умничанье» из исходного поста, имеют решение. О нем многие знают, но делают единицы. Я пишу об этом десятый раз на Хабре, но каждый раз кто-то спорит.
Итак, первое. Бизнес дает деньги сотруднику в первую очередь, а сотрудник уже продолжает цепочку деньги-результат-деньги. Поэтому все бьется на много итераций, на выходе каждой — результат и прибыль.. В современном мире деньги — это скорость, быстрый результат. Поэтому первая версия любого стартапа, или там быстрое решение задачи как в примере поста, должно быть доведено до результата, который приносит прибыль.
НО!
Во-первых, быстрое решение задачи не означает немасштабируемое. Быстрые scalable решения возможные, для этого нужно умничать еще больше, чем долго и тупо делать крутую вещь. Поэтому выход простой. Сначала нужно быстро сделать и довести до конца. Получить обратную связь (смотри выше), заработать денег. Дальше масштабировать решение, используя обратную связь от предыдущего этапа. Эволюция с результатом на каждом этапе является ответом на проблему процесс Vs результат. Результатов должно быть много, часто, и они должны давать почву для развития.
Итак, если подытожить.
— Не следует делать мантру из «работы на результат». Нужно уметь определить, что есть результат.
— Процесс и результат — это единое целое, не нужно противопоставлять эти вещи.
— Для работы бизнеса первична прибыль, для работы бизнеса и сотрудников важна эволюция процесса через постоянные результаты. Итерации рулят.
В этом посте показано, как люди путают несколько вещей, а о чем-то просто не имеют представления.
Путают инструмент и его цели. Любая организация работы, подход к ней, методология имеет свои плюсы и минусы. И если слепо следовать, не думая головой, одним и тем же догмам — пользы не будет.
Конкретно, речь о методологии работы на результат. Слепо повторять «работай на результат», при этом не поломав голову над определением, что же есть результат, глупо и неразумно. Что приводит к плачевным последствиям, что хорошо показано в исходном посте.
Теперь идеологию. Дело в том, что само разделение на результат и процесс весьма условно. Все почему-то забывают, что это — взаимосвязанные вещи. К примеру, для улучшения процесса производства чего-либо нужна отрицательная обратная связь, сравнение получаемого результата с тем, что ожидается. И обратно, результат является следствием процесса, поэтому без настройки процесса результат меняться не будет.
На примере программиста и компании. Когда я спрашиваю у людей, что главнее — мозг, глаз или сердце по отдельности, ответа нет. Потому что человек — это нечто большее, чем органы, это работающая система. Так и фирма — это работающая система. В ней программист — это один из органов, связанных с другими. Если программист будет только заниматься процессом, не выдавая результат (вечный рефакторинг), то фирма ничего не продаст. В конечном итоге поток денег прекратится, и не станет ни фирмы, ни работы у программиста. Поэтому программисты не понимают часто задач бизнеса, а бизнес не понимает задач программиста, только если постоянно не объяснять, что, зачем и как.
Справедливости ради, если не заниматься внутренним процессом производства, то полученный быстрый результат может через год-другой из-за плохого года загубить компанию. Руководителей, которые не понимают, что программисту важны KISS, SOLID, нужные индексы и вообще правильная архитектура и тд, и не дают время на рефакторинг, можно отправить в биореактор. Как фрилансер в прошлом, видя тонны говнокода, где никто не рефакторил (не давали времени людям), говорю со всей ответственностью.
Далее, про представление. Указанные противоречия в прошлом абзаце, а также про масштабируемые системы и «умничанье» из исходного поста, имеют решение. О нем многие знают, но делают единицы. Я пишу об этом десятый раз на Хабре, но каждый раз кто-то спорит.
Итак, первое. Бизнес дает деньги сотруднику в первую очередь, а сотрудник уже продолжает цепочку деньги-результат-деньги. Поэтому все бьется на много итераций, на выходе каждой — результат и прибыль.. В современном мире деньги — это скорость, быстрый результат. Поэтому первая версия любого стартапа, или там быстрое решение задачи как в примере поста, должно быть доведено до результата, который приносит прибыль.
НО!
Во-первых, быстрое решение задачи не означает немасштабируемое. Быстрые scalable решения возможные, для этого нужно умничать еще больше, чем долго и тупо делать крутую вещь. Поэтому выход простой. Сначала нужно быстро сделать и довести до конца. Получить обратную связь (смотри выше), заработать денег. Дальше масштабировать решение, используя обратную связь от предыдущего этапа. Эволюция с результатом на каждом этапе является ответом на проблему процесс Vs результат. Результатов должно быть много, часто, и они должны давать почву для развития.
Итак, если подытожить.
— Не следует делать мантру из «работы на результат». Нужно уметь определить, что есть результат.
— Процесс и результат — это единое целое, не нужно противопоставлять эти вещи.
— Для работы бизнеса первична прибыль, для работы бизнеса и сотрудников важна эволюция процесса через постоянные результаты. Итерации рулят.
В итоге по всему посту можно много критики. С одним лишь согласен — долбоебов как среди руководителей, так и среди исполнителей очень много. Прямо закон 95%, блеять.
>Но тут все гораздо проще: если все всё делают правильно, то и результат будет правильным.
Правильных решений всегда много. И выбирать нужно, в том числе исходя из временных требований, и требований к скорости поставки результата. Важна масштабируемость, вот о чем не написано в посте.
>Если процессы отслеживаются и корректируются в соответствие с глобальными целями и задачами системы (а не выдуманными из головы некомпетентными «консультантами» искусственными метриками), то вы, всей командой, достигнете ваших настоящих (возможно, даже пока неизмышлимых) целей!
Во-первых глобальные цели и задачи меняются (речь о стратегии компании видимо). Рынок, вообще, динамическая система, если что ;-)
Во-вторых, их декомпозиция в «результаты» для каждого человека — это не менее сложная задача, чем написать систему деплоя. Потому что компы работают одинаково, а люди — разные, и тут нет однозначной 100% предсказуемости, в отличие от алгоритма.
Такие дела.
>Но тут все гораздо проще: если все всё делают правильно, то и результат будет правильным.
Правильных решений всегда много. И выбирать нужно, в том числе исходя из временных требований, и требований к скорости поставки результата. Важна масштабируемость, вот о чем не написано в посте.
>Если процессы отслеживаются и корректируются в соответствие с глобальными целями и задачами системы (а не выдуманными из головы некомпетентными «консультантами» искусственными метриками), то вы, всей командой, достигнете ваших настоящих (возможно, даже пока неизмышлимых) целей!
Во-первых глобальные цели и задачи меняются (речь о стратегии компании видимо). Рынок, вообще, динамическая система, если что ;-)
Во-вторых, их декомпозиция в «результаты» для каждого человека — это не менее сложная задача, чем написать систему деплоя. Потому что компы работают одинаково, а люди — разные, и тут нет однозначной 100% предсказуемости, в отличие от алгоритма.
Такие дела.
Еще хочется сказать вот что.
Работать на качество, делать фундаментально можно. И нужно. Тем, кто может.
Если вы, к примеру, Ларри Пейдж. Или, посмотрев с другого ракурса, вы строите дом, или пишете программу для машины Тойота.
Для всего свои требования, свои подходы.
Вот только количество людей, которые считают себя способными написать качественно, так много, что денег на них не хватает. Ведь качественность проверяется результатом, практика — критерий истины, как говорили великие. А сплошь и рядом проваленные стартапы и долгострои, из-за PREMATURE OPTIMIZATION, который is the root of all evil, как говорит доктор Кнут.
Поэтому если вы легко решаете задачи международной математической олимпиады, или изобрели новый PageRank — пожалуйста. Докажите делом, что можете долго делать и получить гениальное.
Большинство претендующих не могут, получается херня, и деньги уходят на ветер.
Работать на качество, делать фундаментально можно. И нужно. Тем, кто может.
Если вы, к примеру, Ларри Пейдж. Или, посмотрев с другого ракурса, вы строите дом, или пишете программу для машины Тойота.
Для всего свои требования, свои подходы.
Вот только количество людей, которые считают себя способными написать качественно, так много, что денег на них не хватает. Ведь качественность проверяется результатом, практика — критерий истины, как говорили великие. А сплошь и рядом проваленные стартапы и долгострои, из-за PREMATURE OPTIMIZATION, который is the root of all evil, как говорит доктор Кнут.
Поэтому если вы легко решаете задачи международной математической олимпиады, или изобрели новый PageRank — пожалуйста. Докажите делом, что можете долго делать и получить гениальное.
Большинство претендующих не могут, получается херня, и деньги уходят на ветер.
Время/деньги/качество. Первый курс института народного хозяйства. Либо лебедь/рак/щука.
Всегда надо работать на результат. Но под ним мы должны понимать не просто «результат», а результат в сочетании время/деньги, деньги/качество, время/качество.
Или када общаешься с конторой, уточни, что мы понимаем под «результатом». Результат быстро != результат качественно.
ТС, а что так много ненависти сквозит? :)
Всегда надо работать на результат. Но под ним мы должны понимать не просто «результат», а результат в сочетании время/деньги, деньги/качество, время/качество.
Или када общаешься с конторой, уточни, что мы понимаем под «результатом». Результат быстро != результат качественно.
ТС, а что так много ненависти сквозит? :)
Статья отличная, но названа неправильно. Всё, что ты написал, правильно, вот только я под «работай на результат» понимаю «делать так, как нужно для фирмы» и противопоставляю этому «делать так, как меня попросили».
То есть если работник исходит из цели «хочу, чтобы прибыль моей фирмы была максимальна», то он работает на результат, а если он исходит из цели «хочу зарплату» или «хочу, чтобы меня похвалил начальник» или «хочу, чтобы начальник ко мне хорошо относился» или «хочу, чтобы МОЯ прибыль была максимальна» — то это работа не на результат.
Кароче говоря, антитезис к «работе на результат» — это «работа на себя». То есть «работа на результат» — это когда работник работает на фирму, то есть он патриот своей фирмы, а «работа не на результат» — это когда работник работает на себя, т. е. он эгоист.
Естественно, в реальной жизни (я думаю) 99% работников работает «на себя» и лишь 1% работает «на фирму», т. е. «на результат».
Из тех примеров, которые ты приводил, как раз Павел работал на результат (в моей терминалогии), а Андрей — нет. Андрею было важно, чтобы начальник его похвалил, чтобы начальник к нему хорошо относился, т. е. Андрей думал о своей собственной выгоде. Андрей хотел как можно быстрее «отвязаться» от этого задания, чтобы задание считалось выполненым. Поэтому он работал не на результат, т. е. он хотел выполнить задание любым способом, не важно, что некачественно. А Павел подумал о том, как сделать правильно. То есть ему важен результат, а не то, что скажет ему начальник. Он готов пожертвовать своей репутацией и пр., ради того, чтобы сделать так, как это будет лучше фирме. Он думал о масштабируемости.
Когда человек хочет выполнить задание качественно — вот это работа на результат. А если человек выполняет задание ровно настолько, насколько его попросили — это работа на себя.
Когда всякие менеджеры провозглашают принцип «работа на результат», они имеют в виду ровно это. Они имеют в виду работу на совесть. Они хотят чтобы сотрудники думали не о похвале, а о результате, о результате для фирмы.
Те, кто работают на результат, они как раз делают всё идеально, то есть добиваются того, чтобы результат был идеален. А те, кто работают не на результат, делают как раз ровно то, о чём их попросили, по принципу «оптимизации энергетических затрат», о котором ты совершенно верно упомянул.
Так вот, я думаю, что большинство людей понимают под результатом то же, что и я. Поэтому твоя статья использует неправильную терминологию. А суть статьи — отличная. Твоя статья как раз доказывает, что работа на результат (в моей терминологии) — это хорошо. Просто очень труднодостижимая. И если менеджеры будут просто провозглашать «работу на результат», то этого мало.
Пожалуйста, ответь мне, если мой коммент тебе понравился. Мне это очень важно.
То есть если работник исходит из цели «хочу, чтобы прибыль моей фирмы была максимальна», то он работает на результат, а если он исходит из цели «хочу зарплату» или «хочу, чтобы меня похвалил начальник» или «хочу, чтобы начальник ко мне хорошо относился» или «хочу, чтобы МОЯ прибыль была максимальна» — то это работа не на результат.
Кароче говоря, антитезис к «работе на результат» — это «работа на себя». То есть «работа на результат» — это когда работник работает на фирму, то есть он патриот своей фирмы, а «работа не на результат» — это когда работник работает на себя, т. е. он эгоист.
Естественно, в реальной жизни (я думаю) 99% работников работает «на себя» и лишь 1% работает «на фирму», т. е. «на результат».
Из тех примеров, которые ты приводил, как раз Павел работал на результат (в моей терминалогии), а Андрей — нет. Андрею было важно, чтобы начальник его похвалил, чтобы начальник к нему хорошо относился, т. е. Андрей думал о своей собственной выгоде. Андрей хотел как можно быстрее «отвязаться» от этого задания, чтобы задание считалось выполненым. Поэтому он работал не на результат, т. е. он хотел выполнить задание любым способом, не важно, что некачественно. А Павел подумал о том, как сделать правильно. То есть ему важен результат, а не то, что скажет ему начальник. Он готов пожертвовать своей репутацией и пр., ради того, чтобы сделать так, как это будет лучше фирме. Он думал о масштабируемости.
Когда человек хочет выполнить задание качественно — вот это работа на результат. А если человек выполняет задание ровно настолько, насколько его попросили — это работа на себя.
Когда всякие менеджеры провозглашают принцип «работа на результат», они имеют в виду ровно это. Они имеют в виду работу на совесть. Они хотят чтобы сотрудники думали не о похвале, а о результате, о результате для фирмы.
Те, кто работают на результат, они как раз делают всё идеально, то есть добиваются того, чтобы результат был идеален. А те, кто работают не на результат, делают как раз ровно то, о чём их попросили, по принципу «оптимизации энергетических затрат», о котором ты совершенно верно упомянул.
Так вот, я думаю, что большинство людей понимают под результатом то же, что и я. Поэтому твоя статья использует неправильную терминологию. А суть статьи — отличная. Твоя статья как раз доказывает, что работа на результат (в моей терминологии) — это хорошо. Просто очень труднодостижимая. И если менеджеры будут просто провозглашать «работу на результат», то этого мало.
Пожалуйста, ответь мне, если мой коммент тебе понравился. Мне это очень важно.
Рядовой сотрудник, айтишник в данном случае, не может знать, что принесёт фирме большую прибыль. Тем более приоритеты краткосрочной перспективы над долгосрочной или наоборот. Фирма должна недвусмысленно показывать работнику каких результатов она от него ждёт. Показывать можно как угодно, хоть похвальбой начальства, хоть премией, хоть внеочередным отпуском, хоть ещё как. Задача менеджмента — создание условий когда работа на себя и работу на фирму превращаются в одно и то же.
В вашей трактовке любой из четверых мог работать на результат (на фирму), а мог на процесс (себя). Может после срыва сроков фирма попала на такие неустойки или штрафы, что обанкротилась и ликвидировалась — разве это работа на результат? А минимизировать расходы фирмы на зарплату в этом году — разве работа на себя?
В вашей трактовке любой из четверых мог работать на результат (на фирму), а мог на процесс (себя). Может после срыва сроков фирма попала на такие неустойки или штрафы, что обанкротилась и ликвидировалась — разве это работа на результат? А минимизировать расходы фирмы на зарплату в этом году — разве работа на себя?
С твоим первым абзацем согласен полностью. Да, ты прав, я изменил своё мнение. Я переборщил в своём комменте. Действительно, сотрудник не должен пытаться догадаться, что там принесёт фирме бОльшую фирму, он должен делать то, что его попросили. Но всё-таки, он должен работать на совесть. То есть он не должен стараться искать лазейки в заданиях, которые ему дали и не должен работать по принципу оптимизации энергетических затрат. Именно это (то есть работу на совесть, отсутствие попыток отлынивать) я называю работой на результат.
А вот твой второй абзац мне не понятен. Я не противопоставляю результат и процесс. В моей трактовке антитезис к работе на результат — это работа на себя, она же тупая исполнительность. А не работа на процесс. Кароче, объясни ещё раз нормально свой второй абзац.
Да, кстати, своим постом ты скорее рушишь не мои рассуждения, а рассуждения из исходной статьи. Смотри: ты говоришь, что «Может после срыва сроков фирма попала на такие неустойки или штрафы, что обанкротилась и ликвидировалась», то есть ты тем самым говоришь, что Павел был не прав, он должен был делать задание быстро, успевать в срок. А значит, был не прав и наш глубокоуважаемый hdablin, так как утверждал, что Павел прав.
P. S. hdablin, по-прежнему жду твоего ответа
А вот твой второй абзац мне не понятен. Я не противопоставляю результат и процесс. В моей трактовке антитезис к работе на результат — это работа на себя, она же тупая исполнительность. А не работа на процесс. Кароче, объясни ещё раз нормально свой второй абзац.
Да, кстати, своим постом ты скорее рушишь не мои рассуждения, а рассуждения из исходной статьи. Смотри: ты говоришь, что «Может после срыва сроков фирма попала на такие неустойки или штрафы, что обанкротилась и ликвидировалась», то есть ты тем самым говоришь, что Павел был не прав, он должен был делать задание быстро, успевать в срок. А значит, был не прав и наш глубокоуважаемый hdablin, так как утверждал, что Павел прав.
P. S. hdablin, по-прежнему жду твоего ответа
С «отлынивать», «искать лазейки», да, полностью согласен, не должен. Хотя нет, может и даже должен, если это принесет пользу фирме хотя бы в том, что он будет свободен для аврала, ликвидации последствий какого-то ЧП. Ну, например, если он точно знает, что скрипт деплоя напишет за несколько минут, вместо того, чтобы потратить на день на оббеганиие нескольких десятков компов. В общем то, что в советские времена называлось «рационализаторством».
Смысл второго абзаца в том, что без знания внутренней мотивации, чисто по внешним факторам мы не можем судить работает человек на результат или на себя. Может тот, кто побежал устанавливать прямо на компы или писать скрипт импорта прямо в БД, экономил не столько свои усилия и/или максимизировал пользу от них, сколько затраты фирмы и/или пользу от них. Пускай заблуждался в ретроспективе, но заблуждался искренне. Может квалификации не хватило, чтобы увидеть в чём-то более полезные фирме альтернативы. Может лишние вопросы у них в организации не приветствуются, а ответственность за вероятный срыв сроков брать на себя не пожелал. Может общая атмосфера у них «один день живём, после нас хоть потоп».
Я оба рушу :) Мир не черно-белый. Но с поправками, что должен работать на совесть, к тебе скорее ближе. при этом не бояться лишний раз переспросить как лучше сделать, если видит не один путь решения задачи. Как-то в ситуации очень похожей на скрипт импорта я переспросил: «это разовая задача и срок действительно важен?», на что получил ответ, что не разовая, но важен и встречный вопрос «а что?». А после ответа «можно сделать так, что процесс несколько минут будет занимать, а не весь день, но не уверен, что за день справлюсь» и после завершения «ручного» импорта было выделено время на автоматизацию процесса, потом и премия :)
Смысл второго абзаца в том, что без знания внутренней мотивации, чисто по внешним факторам мы не можем судить работает человек на результат или на себя. Может тот, кто побежал устанавливать прямо на компы или писать скрипт импорта прямо в БД, экономил не столько свои усилия и/или максимизировал пользу от них, сколько затраты фирмы и/или пользу от них. Пускай заблуждался в ретроспективе, но заблуждался искренне. Может квалификации не хватило, чтобы увидеть в чём-то более полезные фирме альтернативы. Может лишние вопросы у них в организации не приветствуются, а ответственность за вероятный срыв сроков брать на себя не пожелал. Может общая атмосфера у них «один день живём, после нас хоть потоп».
Я оба рушу :) Мир не черно-белый. Но с поправками, что должен работать на совесть, к тебе скорее ближе. при этом не бояться лишний раз переспросить как лучше сделать, если видит не один путь решения задачи. Как-то в ситуации очень похожей на скрипт импорта я переспросил: «это разовая задача и срок действительно важен?», на что получил ответ, что не разовая, но важен и встречный вопрос «а что?». А после ответа «можно сделать так, что процесс несколько минут будет занимать, а не весь день, но не уверен, что за день справлюсь» и после завершения «ручного» импорта было выделено время на автоматизацию процесса, потом и премия :)
Работа — она всегда на «результат», вопрос в том, что кто под ним понимает…
Дополняю свой предыдущий коммент: однажды кто-то спросил моего учителя по математике: «Как результаты олимпиады, которую вы провели?» Он ответил: «Я не проводил эту олимпиаду. Мне просто поручили составить задания и проверить работы. И я это сделал. Во мне есть черта немецкого характера: „Хорошая исполнительность и наплевательское отношение к результату“ » (конечно, же это было сказано в шутку, я щас совершенно не хочу подставлять учителя).
Этот случай отлично показывает, что понимается под «работой под результат». «Работа на результат» противопоставляется «тупой исполнительности». «Работа на результат» — это когда человек действительно заинтересован в результате, когда он хочет, чтобы результат был хорошим, когда он работает на совесть. А антитезис к нему — «буквальная исполнительность» (ну или «работа на себя», как я уже говорил), когда человек делает ровно то, что его попросили и не больше (по принципу оптимизации энергетических затрат), и ему плевать на результат.
Ты просто совершенно всё перепутал в своей статье. Твоя терминология перевёрнута с ног на голову. Именно Андрей — «буквальный исполнитель». А на результат работает как раз Павел.
Ещё раз говорю: ответь мне.
Этот случай отлично показывает, что понимается под «работой под результат». «Работа на результат» противопоставляется «тупой исполнительности». «Работа на результат» — это когда человек действительно заинтересован в результате, когда он хочет, чтобы результат был хорошим, когда он работает на совесть. А антитезис к нему — «буквальная исполнительность» (ну или «работа на себя», как я уже говорил), когда человек делает ровно то, что его попросили и не больше (по принципу оптимизации энергетических затрат), и ему плевать на результат.
Ты просто совершенно всё перепутал в своей статье. Твоя терминология перевёрнута с ног на голову. Именно Андрей — «буквальный исполнитель». А на результат работает как раз Павел.
Ещё раз говорю: ответь мне.
Вообще, и Андрей и Павел — оболтусы. Первый делал глупости, но успел, второй делал правильно, но запорол сроки. На сомом деле им обоим нужно было дойти до момента, когда стало понятно, что можно или «бегать и ставить руками» или «сделать систему развертывания». А дальше идёт письмо непосредственному руководителю (с копией начальнику отдела\департамента) о том, что, мол, вот есть 2 пути: по первому мы сейчас делаем глупости, но успеваем, по второму мы не успеваем немного, но делаем всё верно. И всё, ждать ответа!
Это не дело конечных исполнителей решать, по какому пути идти. Для этого есть начальство, оно распределяет ресурсы, выбирает пути. Оно лучше знает, понадобиться ли в будущем созданный процесс развёртывания, или важна только вот эта, конкретная установка вот именно этого софта, конкретно сегодня.
Каждый своим делом должен заниматься.
Это не дело конечных исполнителей решать, по какому пути идти. Для этого есть начальство, оно распределяет ресурсы, выбирает пути. Оно лучше знает, понадобиться ли в будущем созданный процесс развёртывания, или важна только вот эта, конкретная установка вот именно этого софта, конкретно сегодня.
Каждый своим делом должен заниматься.
Кстати, да. Нужна некая золотая середина — некий Андронный Павел.
Оно лучше знает, понадобиться ли в будущем...
Хорошо, когда так есть, но ситуации, когда исполнители знают потребности на шаг вперед, так как непосредственно выполняют работу тоже бывают.
По этому, я думаю, письмо это хорошо и правильно, но в ответ на него нужно быть готовым получить вопрос о том, а что думает исполнитель.
Свое мнение сразу можно изложить в письме, чтобы избежать лишней итерации: «Предлагаю на утверждение одну из двух альернатив. Плюсы и минусы первого решения такие-то, плюсы и минусы второго — такие-то. Исходя из своего видения задач и перспектив развития фирмы/проекта рекомендую утвердить такой-то вариант, потому что плюс (минус) такой-то наиболее значим в долгосрочной (краткосрочной) перспективе.» Если разговор и возникнет, то он будет уже более предметным.
Это может быть достаточно деликатным вопросом на практике, по этому я и написал, что нужно быть готовым ответить на этот вопрос, но не всегда стоит отвечать на него сразу в первом письме. Зависит, например, от уровня глобальности решаемого вопроса в проекте…
Кстати да, это самый правильный подход. Более того, нужно сразу после отправки этого письма приступить к выполнению предложенного варианта (если это не требует каких-то сверх-затрат). В результате:
1. Если начальство тупит с ответом — мы в любом случае делаем то, что подсказывает здравый смысл. В случае затягивания сроков у нас есть железный аргумент: «Где ответ на мою служебную записку?»
2. Если начальство не компетентно — ответ будет «делай, как считаешь нужным». А мы уже даже начали.
3. Если начальство что-то знает и шарит в вопросе — ответ будет «делай вот так». Сворачиваем удочки и делаем. Хочется свободы — вали строить свой бизнес.
4. Если ответ будет «делай правильно, но чтобы быстро», это значит, что начальство идиоты настолько, что не в состоянии оперировать такими вещами как «выбрать из двух одно» и «прочитать письмо до конца». Из такой фирмы можно и нужно валить с чистой душой.
Везде сплошной профит.
1. Если начальство тупит с ответом — мы в любом случае делаем то, что подсказывает здравый смысл. В случае затягивания сроков у нас есть железный аргумент: «Где ответ на мою служебную записку?»
2. Если начальство не компетентно — ответ будет «делай, как считаешь нужным». А мы уже даже начали.
3. Если начальство что-то знает и шарит в вопросе — ответ будет «делай вот так». Сворачиваем удочки и делаем. Хочется свободы — вали строить свой бизнес.
4. Если ответ будет «делай правильно, но чтобы быстро», это значит, что начальство идиоты настолько, что не в состоянии оперировать такими вещами как «выбрать из двух одно» и «прочитать письмо до конца». Из такой фирмы можно и нужно валить с чистой душой.
Везде сплошной профит.
Представил, лицо свое бывшего начальника… и крик со словами: Мне плевать как это будет работать, дополнительных денег нет, времени тоже… решайте сами я не специалист.
Понятно, почему западные начальники стоят больше российских: с ними можно таким образом взаимодействовать…
очень правильная статья, но к сожалению начальству эти прописные истины объяснять бесполезно, а хабр среднестатистическое «звено принятия решений» не читает. Так что в реальной жизни к моменту выхода новой версии софта, в конторе будут скорее всего работать два Андрея и два Евгения. А когда они начнут не справляться с переустановками, за две копейки на недельку привлекут какого-нибудь студента — родственника заслуженной сотрудницы бухгалтерии и он накосячит на порядок больше чем даже два Андрея. Но выяснится это когда уже оба Андрея уйдут в другую контору «с повышением» и расхлебать попытается один Федор взятый на место двух Андреев (все равно же они там сидят и ничего не делают). Только расхлебать не получится потому что Федор был принят на должность по двум критериям — он согласился на предлагаемую мизерную получку и ему хватило наглости соврать что он действительно знает все 25 языков программирования перечисленных в объявлении о приеме на работу.
PS Забыл еще один критерий — Федору еще нет 30, но есть 15 лет стажа работы :)
PS Забыл еще один критерий — Федору еще нет 30, но есть 15 лет стажа работы :)
Ну может потом оказаться и так, что в отделе Павла узнав что он не успел проверку таки задерживают на день теми ли иными плясками с бубном (да хоть бы и «ключи от офиса потеряли»), а вот начальник Антона радостно узнавший что все программы удалены с удивлением и уже без радости узнает для себя, что бывают такие утилиты которые и хвосты от удаленных программ видят, и удаленные файлики восстанавливают… А петины не восстановят, он тщательно готовился…
В общем спор безсмысленный :)
В общем спор безсмысленный :)
Хоо… Начальнек, который даёт такое указание как будто не в России?
Отдел К — такой же отдел состоящий из стандартных чиновников.
Отдел К — такой же отдел состоящий из стандартных чиновников.
interface Чиновник {
public function дайБабла(BiiigMoney $yea);
}
Есть идеальные вещи, а есть существующие в реальном мире.
Такова жизнь.
Те кто гонятся сейчас за успехом, получить всё и сразу, будут гнаться за ним всю жизнь, ну и получать конечно же, но малыми дозами.
Те же, кто стратегически планирует настигнуть его, реально оценивая сроки, силы, совесть, получают успех потом, но глобальный.
Рано или поздно качественного программиста находят нужные люди.
Те кто гонятся сейчас за успехом, получить всё и сразу, будут гнаться за ним всю жизнь, ну и получать конечно же, но малыми дозами.
Те же, кто стратегически планирует настигнуть его, реально оценивая сроки, силы, совесть, получают успех потом, но глобальный.
Рано или поздно качественного программиста находят нужные люди.
Приятно читать статьи, в которых согласен с каждым словом. Не ради пиара, а для пропоганды идей вставлю ссылку на свою старую заметку на ту-же тему.
Во вас зацепило-то!
Вы слишком много значения приаёте фразе «Работаем на Результат».
На самом деле эту фразу надо пропускать мимо ушей, если только вы не заказчик.
Логично, вы ведь не скажете заказчику, что на самом деле лишь 20% усилий затрачиваете на результат, а остальные 80% на процесс. Ему не важно, как вы получили результат. Менделеев вот утверждает, что ему во сне всё приснилось. Ну, а что? Результат-то более чем. По крайней мере, всех устроил.
Когда вы покупаете телефон, вы же не интересуетесь именами китайских рабочих, благодаря которым вы ежедневно пользуетесь данным устройством. Вам не интересно, чем они обычно обедают, и что, возможно, если бы в столовой им клали не две, а четыре ложки риса (т.е. в 2 раза больше), то производительность подскочила бы в 3 раза и количество брака существенно снизилось бы. Вам всё это не интересно, вам нужен результат — те-ле-фон. И эти китайские рабочие именно на него и работают. Вас устраивает ваш телефон? Если купили и пользуетесь, значит, устраивает.
Вот и говорят заказчикам ровно то, что они хотят услышать.
Понятно же, что всё на самом деле взаимосвязано. Просто это бывает не интересно и не стоит озвучивать.
Другое дело, если у заказчика с вами длительные отношения. Вот тогда заказчику становится интересен и процесс тоже (если заказчик не самодур и мазохист, что тоже не редкость).
Кроме того, сам «результат» можно трактовать по-разному. Например, улучшение процесса — отличный результат. Особенно, если у вас действительно есть этот процесс.
Вы слишком много значения приаёте фразе «Работаем на Результат».
На самом деле эту фразу надо пропускать мимо ушей, если только вы не заказчик.
Логично, вы ведь не скажете заказчику, что на самом деле лишь 20% усилий затрачиваете на результат, а остальные 80% на процесс. Ему не важно, как вы получили результат. Менделеев вот утверждает, что ему во сне всё приснилось. Ну, а что? Результат-то более чем. По крайней мере, всех устроил.
Когда вы покупаете телефон, вы же не интересуетесь именами китайских рабочих, благодаря которым вы ежедневно пользуетесь данным устройством. Вам не интересно, чем они обычно обедают, и что, возможно, если бы в столовой им клали не две, а четыре ложки риса (т.е. в 2 раза больше), то производительность подскочила бы в 3 раза и количество брака существенно снизилось бы. Вам всё это не интересно, вам нужен результат — те-ле-фон. И эти китайские рабочие именно на него и работают. Вас устраивает ваш телефон? Если купили и пользуетесь, значит, устраивает.
Вот и говорят заказчикам ровно то, что они хотят услышать.
Понятно же, что всё на самом деле взаимосвязано. Просто это бывает не интересно и не стоит озвучивать.
Другое дело, если у заказчика с вами длительные отношения. Вот тогда заказчику становится интересен и процесс тоже (если заказчик не самодур и мазохист, что тоже не редкость).
Кроме того, сам «результат» можно трактовать по-разному. Например, улучшение процесса — отличный результат. Особенно, если у вас действительно есть этот процесс.
В статье под результатом понимают результат в плане «пусть фигня, но дёшево и быстро». Или результат в виде бонуса руководителю. В остальном Вы правы, если трактовать «результат» как совершенствование процесса и улучшение качества работы.
Тогда это банальный обман.
И рано или поздно аукнется, не переживайте.
Короче говоря, вот это:
«если все всё делают правильно, то и результат будет правильным»
— верно только в одну сторону.
Правильный результат можно польучить и другим способом (вспоминаем упомянутого Менделеева).
Другое дело, что повторить его вряд ли удастся.
И рано или поздно аукнется, не переживайте.
Короче говоря, вот это:
«если все всё делают правильно, то и результат будет правильным»
— верно только в одну сторону.
Правильный результат можно польучить и другим способом (вспоминаем упомянутого Менделеева).
Другое дело, что повторить его вряд ли удастся.
Это возможно лишь для человека, который в каждой фразе ищет подвох. Да, в современном мире пиара и рекламы невольно начинаешь сомневаться и придираться.
Но фраза эта всё-таки ни причём.
Работать бессистемно в режиме постоянного цейтнота — это зло.
Работать на результат — нет.
Нет никакой связи между первым и вторым.
Но фраза эта всё-таки ни причём.
Работать бессистемно в режиме постоянного цейтнота — это зло.
Работать на результат — нет.
Нет никакой связи между первым и вторым.
Каждый в любой фразе может подразумевать что угодно.
Это реально паранойя какая-то — подозревать каждого в двусмысленности фразы.
Я не согласен с контекстом, он не правомерен.
Презумпция невиновности и всё такое…
Если в компании полный бардак и нет никакой организации, то они могут сказать вам что угодно, но связываться с ними не стоит. Даже если они прочитают этот пост с комментариями и скажут вам «Работаем на Процесс».
По одной фразе делать выводы — надо быть безумцем.
Это реально паранойя какая-то — подозревать каждого в двусмысленности фразы.
Я не согласен с контекстом, он не правомерен.
Презумпция невиновности и всё такое…
Если в компании полный бардак и нет никакой организации, то они могут сказать вам что угодно, но связываться с ними не стоит. Даже если они прочитают этот пост с комментариями и скажут вам «Работаем на Процесс».
По одной фразе делать выводы — надо быть безумцем.
Ну, есть, например, фраза «Я богатый», которую нормальные люди не употребляют (даже если они на чей-то взгляд богаты) — тоже фраза-детектор.
Работать на результат и говорить «мы работаем на результат» — разные вещи. Второе — симптом того, что люди чувствуют, что сказать что-то надо (не то чтобы реально надо что-то сказать — это именно они так чувствуют), а сказать им нечего. Симптом. Что-то скрывают.
Работать на результат и говорить «мы работаем на результат» — разные вещи. Второе — симптом того, что люди чувствуют, что сказать что-то надо (не то чтобы реально надо что-то сказать — это именно они так чувствуют), а сказать им нечего. Симптом. Что-то скрывают.
Вы хорошо осознаёте, что только что огульно обвинили в этом многие компании-гиганты?
«Управляй мечтой», «превосходя ожидания», «идеи для жизни» и т.п.
Фразу я богатый нормальные люди не употребляют, потому что эта фраза не помогает продавать. Хотя люди всё-таки стремятся в Fores Top-100 попасть, что равнозначно произнесению этой фразы.
Фраза «работаем на результат» — помогает продавать. Это рекламный слоган, если хотите, как и перечисленные во втором предложении.
«Управляй мечтой», «превосходя ожидания», «идеи для жизни» и т.п.
Фразу я богатый нормальные люди не употребляют, потому что эта фраза не помогает продавать. Хотя люди всё-таки стремятся в Fores Top-100 попасть, что равнозначно произнесению этой фразы.
Фраза «работаем на результат» — помогает продавать. Это рекламный слоган, если хотите, как и перечисленные во втором предложении.
Вот и говорят заказчикам ровно то, что они хотят услышать.Ну, надо понимать, что к заказчику и к начальнику, который должен разбираться в теме много лучше заказчика, надо относиться по-разному, в частности в плане того, что можно им говорить.
Ключевой смысл лозунга «Работай на результат!» в том, что он подразумевает работу, а не просиживание в офисе от начала и до конца дня. Каждый раз видя на форуме фразу «я сейчас с работы, домой приду и кину вам файл» я думаю, «какого черта вам вообще платят зарплату?».
PS^ сижу на форумах дома или в транспорте с телефона.
PS^ сижу на форумах дома или в транспорте с телефона.
Мне кажется, изначально идёт потеря понимания, так как используется иностранное слово результат = «result».
Словарь Даля даёт такое определение
И если думать по этому определению, то этот самый «результат» в любом случае будет, так как у любого начатого дела будет окончание. Чем окончится дело это уже следующий вопрос. Но таким «результатом» может стать как и успешно оконечное дело, так и не успешно. Что считать успехом тоже вопрос.
Словарь Даля даёт такое определение
РЕЗУЛЬТАТ
муж., франц. следствие чего-либо, последствие, конечный вывод, итог, развязка, исход, конец дела.
И если думать по этому определению, то этот самый «результат» в любом случае будет, так как у любого начатого дела будет окончание. Чем окончится дело это уже следующий вопрос. Но таким «результатом» может стать как и успешно оконечное дело, так и не успешно. Что считать успехом тоже вопрос.
С моей точки зрения — статья хреновая и демотивирующая. Такие надо скручивать в трубочку и засовывать в одно место автору. Да, конечно, меня сейчас опять жестко заминусуют как и в новых 10 отмазках для программистов (статья «почему программисты не успевают в срок»), но кто-то же должен сказать это.
Во-первых, все программисты страдают болезнью «готово на 99%», которое никогда не готово. Любимое слово рефакторинг, «теперь я знаю, как сделать с чистого листа сразу лучше» и т.д. — причем все это рекурсивно. Когда будет доделано — появится желание рефакторить еще и еще.
Во-вторых, автор явно любит работать в спокойном ритме и вся лишняя суета его просто раздражает. Он из серии в 9:00 пришел, в 18:00 ушел. И интересно ему не то, для чего он это делает, а просто сам факт, что он что-то делает, где есть интересные (а может и нет) ему моменты.
Ориентация на результат — это не быдло-код, и не бегание по офису с дискеткой, как вы описали. Данные примеры показывают, что вы вообще не понимаете, что означает это выражение. И, к сожалению, многие его пишут в резюме, выдают лозунгами и девизами… точно так же как и вы не понимая, о чем они говорят.
Если вдуматься в сами слова «ориентированность на результат» становится как бы понятно, на что должна ориентироваться организация и сотрудники (да, Кэп мне подсказывает). Любые задачи решаются с точки зрения того, что отсекается все лишнее, не выполняется параллельно куча лишней работы, все направлено на достижение качественного результата в кратчайшие сроки.
Далее все зависит от того, как именно ставятся задачи. В данном случае техн. дир (в ваших примерах) не был ориентирован на результат. Он должен был решить — будет ли задача повторяющейся, или это разовая необходимость. В случае, если разовая — он сделал все правильно. В случае, если он видит, что подобная вещь будет повторяться периодически — он поставит иную задачу — автоматизировать развертывание ПО.
С вашими быдло-кодерами аналогично. Поставленная задача конечная или нуждается в дальнейшей поддержке и развитии? Дальше вы и сами догадаетесь…
Во-первых, все программисты страдают болезнью «готово на 99%», которое никогда не готово. Любимое слово рефакторинг, «теперь я знаю, как сделать с чистого листа сразу лучше» и т.д. — причем все это рекурсивно. Когда будет доделано — появится желание рефакторить еще и еще.
Во-вторых, автор явно любит работать в спокойном ритме и вся лишняя суета его просто раздражает. Он из серии в 9:00 пришел, в 18:00 ушел. И интересно ему не то, для чего он это делает, а просто сам факт, что он что-то делает, где есть интересные (а может и нет) ему моменты.
Ориентация на результат — это не быдло-код, и не бегание по офису с дискеткой, как вы описали. Данные примеры показывают, что вы вообще не понимаете, что означает это выражение. И, к сожалению, многие его пишут в резюме, выдают лозунгами и девизами… точно так же как и вы не понимая, о чем они говорят.
Если вдуматься в сами слова «ориентированность на результат» становится как бы понятно, на что должна ориентироваться организация и сотрудники (да, Кэп мне подсказывает). Любые задачи решаются с точки зрения того, что отсекается все лишнее, не выполняется параллельно куча лишней работы, все направлено на достижение качественного результата в кратчайшие сроки.
Далее все зависит от того, как именно ставятся задачи. В данном случае техн. дир (в ваших примерах) не был ориентирован на результат. Он должен был решить — будет ли задача повторяющейся, или это разовая необходимость. В случае, если разовая — он сделал все правильно. В случае, если он видит, что подобная вещь будет повторяться периодически — он поставит иную задачу — автоматизировать развертывание ПО.
С вашими быдло-кодерами аналогично. Поставленная задача конечная или нуждается в дальнейшей поддержке и развитии? Дальше вы и сами догадаетесь…
Автор показал, что «ориентация на результат» — это тавтологический buzzword для оправдания чего угодно.
Начальство, неспособное адекватно решить, «будет ли задача повторяющейся, или это разовая необходимость» и чем одно по последствиям отличается от другого, — это на сегодня в РФ данность. И надо что-то делать в рамках этой данности.
Насчёт «быдло-кодеров» — как показывает практика, внезапно любая задача может начать нуждаться в дополнительной поддержке.
Начальство, неспособное адекватно решить, «будет ли задача повторяющейся, или это разовая необходимость» и чем одно по последствиям отличается от другого, — это на сегодня в РФ данность. И надо что-то делать в рамках этой данности.
Насчёт «быдло-кодеров» — как показывает практика, внезапно любая задача может начать нуждаться в дополнительной поддержке.
Андрей и Женя из статьи мыслили тактически, а их «не нацеленные на результат» коллеги больше стратегически. Вот и вся разница. Однако стратегия все-таки важнее чем тактика.
Никакие тактические успехи не могут компенсировать стратегические просчёты. (с) Карл фон Клаузевиц
Никакие тактические успехи не могут компенсировать стратегические просчёты. (с) Карл фон Клаузевиц
Статья правильная но называться она должна была иначе. А в примерах не противопоставление ориентировки на результат, или процесс. Просто разное понимание результата.
И тут просто выполняя задачу нужно понимать: Это мне сейчас надо единоразово сделать импорт в базу чтоб обновить до новой версии софта, или же это перманентный процесс. И где гарант что повторная похожая задача возникнет раньше чем через полгода-год, когда старый «скрипт» на который потрачено три дня (когда дедлайн один) не похерится в куче аналогичного хлама (а у таких вот «умных» чуваков, как раз такого хлама жопой жуй). И он не примется писать этот скрипт повторно, опять проебет все сроки. А тот который тупо сделал руками опыть просто сделает руками и забудет.
Спорно это всё. Мозгами надо думать приступая к задаче.
Бредом будет и невъебенное апи для одноразовой задачи.
Ровно как и обработка руками для периодической.
И тут просто выполняя задачу нужно понимать: Это мне сейчас надо единоразово сделать импорт в базу чтоб обновить до новой версии софта, или же это перманентный процесс. И где гарант что повторная похожая задача возникнет раньше чем через полгода-год, когда старый «скрипт» на который потрачено три дня (когда дедлайн один) не похерится в куче аналогичного хлама (а у таких вот «умных» чуваков, как раз такого хлама жопой жуй). И он не примется писать этот скрипт повторно, опять проебет все сроки. А тот который тупо сделал руками опыть просто сделает руками и забудет.
Спорно это всё. Мозгами надо думать приступая к задаче.
Бредом будет и невъебенное апи для одноразовой задачи.
Ровно как и обработка руками для периодической.
«Обработка руками для периодической задачи» — не обязательно бред. Может быть полезно несколько раз выполнить задачу вручную, чтобы понять, на какие особенности ситуации надо обращать особое внимание. И чтобы потом легче понять, где именно ошибся автомат.
Ну как бы да, без критической массы данных для проектирования автоматизации — проектировать и автоматизировать будет нечего. В любом случае нужно будет что-то там проанализировать. Если не наберется хотя бы парочки вариантов обработки вручную — анализировать будет нечего.
Просто я воспринимал такой анализ как неотъемлемую часть процесса автоматизации, потому не акцентировал на этом внимание.
Просто я воспринимал такой анализ как неотъемлемую часть процесса автоматизации, потому не акцентировал на этом внимание.
Павлу и Антону следовало бы сначала оценить сроки обоих вариантов решения задачи и затем поставить руководителя в известность: «Могу сделать так-то за столько-то, а могу так-то в два раза дольше, но зато в следующий раз будет на порядок быстрее (будет работать с новыми версиями)», и только потом приступать ко второму варианту, если ему дали добро. Иначе, располагая неполной информацией, их инициатива может быть убыточной для бизнеса (например, завтра дедлайн, а по условиям контракта за непопадание в сроки налагается существенный штраф, либо просто не требуется работа с новыми версиями или повторяемость процесса, тогда не нужно нарушать принцип KISS). Адекватному руководителю всегда виднее, какой вариант будет лучше.
Ну а Андрей и Евгений просто низкосортные «специалисты», которых не интересует собственный рост, успешность компании, качество результата.
В общем, все четверо, на мой взгляд, поступили неправильно. Но статья великолепна.
Ну а Андрей и Евгений просто низкосортные «специалисты», которых не интересует собственный рост, успешность компании, качество результата.
В общем, все четверо, на мой взгляд, поступили неправильно. Но статья великолепна.
Адекватному руководителю всегда виднее, какой вариант будет лучше.
Все герои напоминают анекдот «что тут думать, тут прыгать надо!».
В случае Павла и Андрей обоим прежде чем делать, надо было бы подумать о том а) что делать, б) с какой целью.
Конечно, если предполагается поддерживать решение, то надо делать правильно, пусть и с бОльшими затратами на первоначальном этапе.
А если нет? Если эта задача одноразовая? Зачем тратить на задачу больше ресурсов, чем необходимо? А часто для таких одноразовых задач самое простое решение — решение в лоб, на коленке.
В случае Павла и Андрей обоим прежде чем делать, надо было бы подумать о том а) что делать, б) с какой целью.
Конечно, если предполагается поддерживать решение, то надо делать правильно, пусть и с бОльшими затратами на первоначальном этапе.
А если нет? Если эта задача одноразовая? Зачем тратить на задачу больше ресурсов, чем необходимо? А часто для таких одноразовых задач самое простое решение — решение в лоб, на коленке.
Нормально. Лучше сделать что-то на троечку, чем не сделать этого на пятерку.
А если надо сделать, то надо сделать. Завтра может не настать, а сегодня точно придут заказчики с пиздюлями.
А если надо сделать, то надо сделать. Завтра может не настать, а сегодня точно придут заказчики с пиздюлями.
В моих глазах формулировка «Ориентированность на результат» означает то что мы не будем делать того, что никоим образом не приблизит нас к результату.
Почему так? Потому что ориентированность означает направление, т.е. выполнение каждой мелкой задачи должно нас двигать в направлении к результату, в противном случае игнорировать задачи и пропускать их.
К примеру порой можно забить на красоту кнопочки в интерфейсе, если по сути они ничего не меняет.
Слишком большая трата времени на некоторые недостатки, которые не меняют в сущности ничего это и есть главная проблема, которую решают постановкой «ориентированности на результат».
Почему так? Потому что ориентированность означает направление, т.е. выполнение каждой мелкой задачи должно нас двигать в направлении к результату, в противном случае игнорировать задачи и пропускать их.
К примеру порой можно забить на красоту кнопочки в интерфейсе, если по сути они ничего не меняет.
Слишком большая трата времени на некоторые недостатки, которые не меняют в сущности ничего это и есть главная проблема, которую решают постановкой «ориентированности на результат».
Видно, что, в общем, ни «быстротолюбы» ни «правилолюбы» из примеров не имеют достаточного опыта и компетенции в решении поставленной задачи. Т.е. решить вроде как способны, хотя раньше этим никогда не занимались, а адекватно оценить временные затраты для разных вариантов — нет.
С другой стороны, откуда этому опыту взяться и не уйдут ли они, набравшись этого опыта, на более привлекательное место работы…
С другой стороны, откуда этому опыту взяться и не уйдут ли они, набравшись этого опыта, на более привлекательное место работы…
Хорошо, когда исполнители — не Равшан и Джумшуд, а еденицы мыслящие. Не ждущие указаний, а способны и сами проявить инициативу, подсказать, уточнить задачу и так далее.
все так! Но пока, по факту, я сталкиваюсь с тем, что в связи с недостатком обучения программированию и базам данных — то что делают программисты, считая «Правильным способом», ничем не отличается от костыльного говнокода. Я не имею ввиду тебя, я не видел твой код еще.
Проблема в том, что основы программирования среди всех моих 20+ программеров, которые работали — от силы знал 1 или 2. Все остальные — самоучки, САМи считающие что они знают как надо.
В итоге получалось — делали ли они говнокод по моему заданию, или делали супер-пупер расширяемую систему — получалось одно и то же — только разница во времени была в несколько раз.
И НИ РАЗУ!!! Не зависимо от того как было сделано, я не смог использовать существующий код в другом проекте. Вот тебе и факт.
Теперь в ситуации текущего проекта, который мне нужно сдать как можно быстрее — я конечно выберу «говнокод», так как он имеет выигрыш во времени. Других отличий нет.
Я буду очень рад, если хотя бы ОДИН раз, существующий код будет использован в другом проекте и снизит трудоемкость этого участка до банального копипаста. Пока я этого не наблюдаю.
Проблема в том, что основы программирования среди всех моих 20+ программеров, которые работали — от силы знал 1 или 2. Все остальные — самоучки, САМи считающие что они знают как надо.
В итоге получалось — делали ли они говнокод по моему заданию, или делали супер-пупер расширяемую систему — получалось одно и то же — только разница во времени была в несколько раз.
И НИ РАЗУ!!! Не зависимо от того как было сделано, я не смог использовать существующий код в другом проекте. Вот тебе и факт.
Теперь в ситуации текущего проекта, который мне нужно сдать как можно быстрее — я конечно выберу «говнокод», так как он имеет выигрыш во времени. Других отличий нет.
Я буду очень рад, если хотя бы ОДИН раз, существующий код будет использован в другом проекте и снизит трудоемкость этого участка до банального копипаста. Пока я этого не наблюдаю.
Честно говоря, не уловил где тут процесс. Тут есть разного качества результат, разного уровня абстракции или удобства поддержки, если хотите. Но нет процесса.
Вот если бы вместо того, чтобы делать автоматическую деплой-систему, персонаж написал инструкции и регламенты как устанавливать, кто устанавливает, в каком порядке, как оценивать качество и скорость его работы, какие нормативы — это уже было бы что-то близкое к процессу. А потом уже по ним запустил работать младшего инсталлятора. Или двух. Или дюжину. Главное тут что их почти не пришлось бы обучать основам работы в этой компании, потому что, действуя по инструкции, они результат таки получат, и качественный.
Вот если бы вместо того, чтобы делать автоматическую деплой-систему, персонаж написал инструкции и регламенты как устанавливать, кто устанавливает, в каком порядке, как оценивать качество и скорость его работы, какие нормативы — это уже было бы что-то близкое к процессу. А потом уже по ним запустил работать младшего инсталлятора. Или двух. Или дюжину. Главное тут что их почти не пришлось бы обучать основам работы в этой компании, потому что, действуя по инструкции, они результат таки получат, и качественный.
С примерами не совсем согласен: на лицо ошибка менеджера, который неверно поставил задачу, вернее не рассказал как нужно сделать и ошибка исполнителя, который не предусмотрел расширяемость.
Но в целом мысль статьи правильная: нужно требовать не только достижение цели любыми способами, но и соблюдения стандартов качества, при этом.
Но в целом мысль статьи правильная: нужно требовать не только достижение цели любыми способами, но и соблюдения стандартов качества, при этом.
Завершая аналогию с сексом, получается, что, как было написано, процесс важнее результата, но важнее процесса — любовь. Любовь к своему делу, к изящному коду, к добротным решениям — не формализуешь.
Автору рекомендую книгу Ф. Зимбардо «Парадокс времени». Если кратко, то ориентация на результат = ориентация на будущее, ориентация на процесс = ориентация на настоящее. По концепции временных перспектив неэффективно быть ориентированным на прошлое, настоящее и будущее. Эффективно иметь сбалансированную временную перспективу, чтобы уметь переключаться из одной в другую под ситуацию. Например, неэффективно, быть ориентированным на будущее, когда находишься на отдыхе. Тут желательно быть ориентированным на настоящее, чтобы замечать пение птиц, шум моря. Но, быть ориентированным на настоящее, когда планируешь стратегию развития организации на 5 лет вперед — вредно. Тут лучше временная перспектива будущего.
technical debt explained: )
Автор считает что его герои имеют одинаковую производительность, просто имеют разный подход и как следствие выполняют работу за разное кол-во времени. И симпатии в этом случае оказываются на стороне героя проявившего несколько большее понимание процесса и занявшегося (в обоих случаях) его автоматизацией, вместо решения задачи «в лоб». Однако, в жизни это слегка не так.
Предположим, на минутку, что человек выполняющий всё «по науке» не имеет ту же производительность, что и человек решающий «в лоб». А просто «тормоз». Причём «тормоз» по жизни.
Начальник поставил задачу Андрею и Константину внести по одному тегу в HTML-код некого сайта, каждому (задача одинаковой сложности). Андрей открыл блокнот, внёс, сохранил, проверил локально, убедился что всё нормально и выгрузил в production. Константин открыл habrahabr и стал искать какой редактор сейчас наиболее популярен у верстальщиков. На это он потратил два дня и на вопрос начальника: «как поживают изменения на сайте сроком вчера», ответил что они «в процессе». Нам «шашечки или ехать», в этом контексте приобретает совершенно другой смысл.
И к сожалению, число людей которые не умеют верно расставлять приоритеты гораздо (я думаю, на порядки) больше числа тех кто бездумно ориентирует «на результат».
Предположим, на минутку, что человек выполняющий всё «по науке» не имеет ту же производительность, что и человек решающий «в лоб». А просто «тормоз». Причём «тормоз» по жизни.
Начальник поставил задачу Андрею и Константину внести по одному тегу в HTML-код некого сайта, каждому (задача одинаковой сложности). Андрей открыл блокнот, внёс, сохранил, проверил локально, убедился что всё нормально и выгрузил в production. Константин открыл habrahabr и стал искать какой редактор сейчас наиболее популярен у верстальщиков. На это он потратил два дня и на вопрос начальника: «как поживают изменения на сайте сроком вчера», ответил что они «в процессе». Нам «шашечки или ехать», в этом контексте приобретает совершенно другой смысл.
И к сожалению, число людей которые не умеют верно расставлять приоритеты гораздо (я думаю, на порядки) больше числа тех кто бездумно ориентирует «на результат».
Давний анекдот в тему:
Идет обезьяна по пустыне, жаpко, пить хочется.
И вдpуг видит: стоит пальма, а на ней — кокос.
Hу обезьяна начинает тpясти ее, а внутpенний голос говоpит:
" Обезьяна, подумай! ".
Обезьяна подумала, взяла палку, сбила кокос и напилась…
Идет студент по пустыне, жаpко, пить хочется.
И вдpуг видит: стоит пальма, а на ней — кокос.
Hу студент начинает тpясти ее, а внутpенний голос говоpит:
" Студент, подумай! ".
— Чего тут думать, тpясти надо!
Идет обезьяна по пустыне, жаpко, пить хочется.
И вдpуг видит: стоит пальма, а на ней — кокос.
Hу обезьяна начинает тpясти ее, а внутpенний голос говоpит:
" Обезьяна, подумай! ".
Обезьяна подумала, взяла палку, сбила кокос и напилась…
Идет студент по пустыне, жаpко, пить хочется.
И вдpуг видит: стоит пальма, а на ней — кокос.
Hу студент начинает тpясти ее, а внутpенний голос говоpит:
" Студент, подумай! ".
— Чего тут думать, тpясти надо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что плохого в работе на результат