ИМХО, в этой статье автор пытается сказать только одно, что каждый сам себе «злобный Буратино». Ведь приглашают этих консультантов руководители, и они сами определяют каким образом консультанты должны им советовать.
Автор дает вполне вменяемую стратегию для работы с консультантами (спускать их на уровень — два ниже и толкать инициативы снизу.)
В моей практике встречалась ситуация (правда не в разработке, а в маркетинге) где консультанты отработали по «циклу Деминга» причем в явном виде. Только еще можно было бы добавить блок — дискредитация среднего менеджмента, если он сопротивляется бредовым идеям. И тут впорос больше к руководителям, кому он больше доверяет, своим сотрудникам, или пришлым консультантам. (ИМХО — верить можно только себе и то в крайнем случае :))
Примеры как раз релевантны и вот почему:
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.
В этом и состоит весь секрет.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
Тут скорее нужен другой коэффициент — время безаварийной работы — время когда нет заявок с грифом системная ошибка.
И скорость устранения для заявок с меткой — операционная.
Мы не знаем каким изменениям, с помощью макросов и черной магии, подвергся Excel чтоб стать таск-трекером, но не сомневаюсь что это возможно. Я однажды видел еxcel который вел бух учет предприятия, так что после этого, я ничему не удивляюсь.
Ну так тема то действительно большая и объемная.
Отнюдь, реализация не позволяла ни вменяемо масштабироваться ни держать нагрузку, но задачу свою с небольшим потоком пользователей — решала. На счет ручейка не берусь судить. Ну так я же с самого начала говорил, что прикладное программирование это НЕ ПЛОХО, просто не для всех задач подходит, как и инженерная разработка. Важно понять когда хорошо одно и когда хорошо другое. Причем, зачастую одно не исключает другого.
Ну так, чисто для справки, проблемы решали тоже аутсорсеры :)
1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще.
2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим.
3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет.
4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно.
Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился. ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками :) Ведь проект мог и «не выстрелить»
Вот пример из жизни. Нужно было создать потенциально интересный людям сервис обработки и хранения данных, заказчик выбрал компанию которая сказала что сделает быстро и не дорого. В итоге сделала, не очень быстро, но сделала, и через 2 (два) месяца эксплуатации системы её пришлось ПОЛНОСТЬЮ переписывать, по тому что ввиду использования различных левых библиотек — оптимизация проекта была ниже плинтуса, и сервис падал от слова совсем уже при 1000 униках. Да, по итогу мы потратили не 3 месяца на разработку, а больше, зато проект не падает и стабильно развивается, доработки в рамках логики проекта не отнимают огромное количество времени на тестирование «а вдруг что отвалилось, где не ждали».
Понятно что для того чтоб написать визитку — нет смысла делать множество абстракций и каждый раз разрабатывать свою цмс, но для сложных и потенциально высоко нагруженных проектах бездумно использовать кучу чужих библиотек… это далеко не самое правильное решение.
Вот только «отрефакторить», в некоторых случаях, означает тоже — заменять сразу целиком. Фатальные ошибки возможны при любых раскладах. Я в своей жизни видел проекты которые до сих пор отлично выполняют поставленные задачи и на fox.pro требующие минимум поддержки и никуда не годящиеся решения которые пришлось полностью менять на yii. Видел и обратное. Но это больше относится не столько к разработчикам, сколько к заказчикам и изменчивости требований к системам.
Не стоит говорить и «инжинер» — настоящий программист а «кодер» — не программист, по тому что каждый из этих типов может является настоящим программистом, просто один склонен «изобретать велосипеды», другой «приделывать к велосипедам костыли». отличать путем общения и понимания личных предпочтений каждого в отдельности. Опять же скажу что нельзя сказать кто более важен, для процесса разработки нужны оба типа.
На мой, сугубо личный взгляд, следует очень сильно различать инженеров — программистов и «кодеров». Если первым поручить задачу «сделай чтоб это считало так» мы на выходе получим уйму потраченого времени, и уникальное решение которое будет решать эту задачу. Если мы попросим сделать ту же задачу «кодера» то мы получим решение этой же проблемы на основе другого решения, с меньшими затратами труда. НО если мы поручим «кодеру» написать что-то серьезное, мы получим решение быстрее, но сложнее в поддержке и, скорее всего, более уязвимое, ввиду использования большого количества разношерстных библиотек. По итогу, как сказал оратор выше. «Все профессии важны, все профессии нужны.»
Согласен со всем, кроме самого первого предложения. То, что описано, не укладывается в портрет «типичного заказчика», скорее в портрет «хорошего заказчика».
Согласен со всем, кроме самого первого предложения. То, что описано, не укладывается в портрет «типичного заказчика», скорее в портрет «хорошего заказчика».
Как правило, стоимость технического задания включается в стоимость разработки и не выносится отдельными пунктами. Оно вроде как бесплатно, хотя по факту таковым и не является. Собственно точно так же, как и "бесплатные концепции".
Вопрос появился в связи с тем, что в кейсах не увидел у вас разработку ТЗ для верстки и программирования в большинстве случаев. А если это делается так же как в большинстве студий (стоимость этого разбивается в остальные части), возникает непонимание, почему один тип работ — вы выносите в доп. оплату а другой нет, или это чтоб получить конкурентное преимущество? :)
Повеселила строчка «и радостно просит сделать ему «аджайл» и «скрам»»
А если серьезно. Как правило, «бесплатные» концепции закладываются в стоимость проектов и получается вполне так реальное конкурентное преимущество, оплаченное при получении заказа.
Другой вопрос какой процент с проекта/проектов следует закладывать в это, и как к реализации концепции подходить. Ведь и написание ТЗ для разработчиков тоже работа, и тоже должна делаться, и по хорошему она должна быть детальней «это форма — она должна отправлять лид».
Отсюда вопрос к автору, а за техническое задание для верстальщиков и программистов тоже берете деньги?
Автор дает вполне вменяемую стратегию для работы с консультантами (спускать их на уровень — два ниже и толкать инициативы снизу.)
В моей практике встречалась ситуация (правда не в разработке, а в маркетинге) где консультанты отработали по «циклу Деминга» причем в явном виде. Только еще можно было бы добавить блок — дискредитация среднего менеджмента, если он сопротивляется бредовым идеям. И тут впорос больше к руководителям, кому он больше доверяет, своим сотрудникам, или пришлым консультантам. (ИМХО — верить можно только себе и то в крайнем случае :))
Мой отец может разобрать и собрать машину отечественного производства и иностранного до 90х годов. Любую, где не используется компьютер. Заменить ГРМ, перебрать клапана, починить карбюратор из подручных средств — для него не проблема, и экстренно починить заглохший двигатель с помощью гвоздя и резинки тоже (сам видел). При этом скажет сколько она проедет до следующей такой же проблемы. И он, отец, не механик, а простой советский инженер. При этом при обращении с современными машинами, он вынужден обращаться в сервис, и вынужден доверять тем специалистам которые обслужат машину, и их квалификацию, как и результат может проверить только очень поверхностно, как работают эти контроллеры и компьютеры он не знает, при этом постоянно проверяя за сервисными работниками то, что он знает. При этом мой знакомый который работает в мастерской и настраивает электронику в машинах — говорит что все делает по документации и не лезет внутрь.
Так вот, к чему я это написал. В современном мире мы все дальше уходим от понимания принципов работы системы даже среднестатистическим инженером, не говоря уже о конкретном пользователе, и дальше будет хуже.
Мы будем использовать продукты в рамках инструкций не разбираясь в запасах прочности и допусках и вариантах замены в экстренных ситуациях. Мы не сможем экстренно починить заглохший двигатель с помощью гвоздя и резинки.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
И скорость устранения для заявок с меткой — операционная.
Отнюдь, реализация не позволяла ни вменяемо масштабироваться ни держать нагрузку, но задачу свою с небольшим потоком пользователей — решала. На счет ручейка не берусь судить. Ну так я же с самого начала говорил, что прикладное программирование это НЕ ПЛОХО, просто не для всех задач подходит, как и инженерная разработка. Важно понять когда хорошо одно и когда хорошо другое. Причем, зачастую одно не исключает другого.
1) вы будете удивлены, но очень многие проекты в том числе и весьма сложные делаются или на аутсорсе, или с привлечением аутсорсеров, по тому что это правильнее, эффективнее и проще.
2) Заказчик исходил из вашего постулата, быстро собрать, а потом посмотрим.
3) Было, единственное что не было учтено — это нагрузки которые могут возниктнуть, это был стартап и было не понятно взлетит или нет.
4) Нужно понимать что, когда и как использовать. Я не говорю о том, что нужно постоянно изобретать велосипед, но и бездумно пользоваться готовыми решениями тоже не правильно.
Вообще не понимаю, почему вы считаете что заказчик сделал все чтоб проект провалился. ИМХО Заказчик сделал все вполне правильно с точки зрения бизнеса. Потратил часть ресурсов чтоб проверить насколько проект будет востребованным, когда убедился что проект будет востребован — потратил еще ресурсы чтоб сделать его эффективным. Это называется управление рисками :) Ведь проект мог и «не выстрелить»
Понятно что для того чтоб написать визитку — нет смысла делать множество абстракций и каждый раз разрабатывать свою цмс, но для сложных и потенциально высоко нагруженных проектах бездумно использовать кучу чужих библиотек… это далеко не самое правильное решение.
А если серьезно. Как правило, «бесплатные» концепции закладываются в стоимость проектов и получается вполне так реальное конкурентное преимущество, оплаченное при получении заказа.
Другой вопрос какой процент с проекта/проектов следует закладывать в это, и как к реализации концепции подходить. Ведь и написание ТЗ для разработчиков тоже работа, и тоже должна делаться, и по хорошему она должна быть детальней «это форма — она должна отправлять лид».
Отсюда вопрос к автору, а за техническое задание для верстальщиков и программистов тоже берете деньги?