Вы другими словами изобрели заново идеалистическую концепцию Мира как Воли и Представления Шопенгауэра. Прежде чем писать о чем-то философском, ознакомьтесь, пожалуйста, с базовыми понятиями философии.
Хорошие, универсальные в целом советы. Добавил бы только про необходимость на опыте доказывать свою точку зрения, так как даже лиды иногда бывают не правы (редко, конечно). Чаще всего пригождается навык оценки задач и его доказательства перед ПМ. С этим навыком и сам в голове составляешь план на задачу и решать ее проще.
"Подрывают авторитет руководителей и собственника компании, т.к. складывается впечатление, что они принимают неэффективные решения." То есть это не владельцы с манагерами придумали странный подход и всех переучивают, и их решение может быть неэффективным, а "впечатление". А несогласных просто уволить - если подкупить и пригрозить контролем не помогает. Отличная статья! Правда я бы добавил еще как вариант плеть и рудники, но до такого уровня раболепства еще надо добраться.
Вы просто из головы тащите какие-то ложные аналогии. Что в статье ложная, что тут. Так в статье про собаку, утку и охотника вообще иначе было написано. Скажу только, что задачи - не утки, разработчик - не ваш пёс, что тащит по первому указанию, а вы не охотник. В метафоре про собаку все по-идиотски просто, (получил приказ - принёс утку). Но жизнь сложнее, сори. Ответ на ваш вопрос: решил заняться своими делами - значит они важнее, решил сделать задачу - значит было решение разработчика её сделать. Если работа не сделана, а он обещал, то это или ошибка, что взяли человека, или неправильно объяснили как и что сделать. Ещё задавайте простые банальные вопросы, прошу)
Чтобы контролировать работу приложения в целом, мыслить его в максимально большом масштабе. Связываться почти со всеми в команде. Это не тот, кто мыслит "идеального сотрудника" или тот, кто командует взять "утку". Условно, все более-менее нормальные лиды не мыслят себя манагерами, а разработчиками или тестерами.
Лидер должен быть у племени. В разработке ПО должны быть финансовые ресурсы, специалисты, окружение и техника. Когда лидеров нет, есть продуктивность и каждый делает свою работу.
Никаких "руководителей" быть вовсе не должно - каждый в команде выполняет свою часть задач. Менеджер - планирование, коммуникации между сотрудниками и с клиентами, разработчик делает софт, тестировщик обеспечивает качество. Вопрос про идеального сотрудника эквивалент вопроса идеального раба у древнегреческих философов. Почему история про собаку и охотника идиотская? Просто у вас нет критерия, что является неразрешимой задачей (охотник сказал собаке достать Луну), и я уж молчу, что вообще-то идеальный сотрудник - это не тот, кто сделает вашу задачу качественно (даже про срок нет разговора, значит второй ваш пример про Артура и есть ответ на проблему статьи). Это человек, а не машина (возвращаемся к аллегории раба). Надеюсь никогда не буду с вами работать)
Очевидно, очередной неадекватный эйчар-иинструмент, который по определению не способен отразить обладание скиллами и легко служит способом не повышать зп или не выдавать премию. Во-первых, коллеги чаще всего не способны адекватно оценить своего коллегу по фрагментам его знаний (код ревью не в счет, элементарный рандом при планировании). В моем случае все бэкендеры всегда ставили оценки максимум или 4 из 5 во всех сферах. Да и по приведенным примерам надо чуть ли не сессию каждому разрабу оформлять. Во-вторых, коллегам не всегда выгодно честно отвечать на поставленные тематики (когнитивные искажения, привет). Чаще всего именно тимлид отвечает честно и по делу, потому что конечное решение за ним. В-третьих, результаты любых оценок можно исказить так, как угодно, веса то устанавливаются теми, кто решает вопрос о повышении :) Получается, что если разработчик с командой запустит новый сервис, но разработчики недостаточно хорошо его оценили, то повышения и премии ему не видать, даже если новый сервис приносит миллионы компании. В целом, неясно зачем нужно было это приложение, почему нет прозрачной работы с весами и где гарантии честности. Excel по духу все-таки близок.
В подавляющем числе проектов и по практикам мету не используют и правильно делают. Класс - основа для проектирования и работы самого языка, осмысленные данные такого типа упаковывать в него логично по содержанию. 4 пункт явно очень спорный, отбраковывать кандидатов из-за немного другого подхода, который вам не нравится, но не является ошибкой ни в коем случае - самодурство.
Текст очевидного максималиста. Кабан Кабаныч будет рад всему что здесь перечислено. Например, "Выражения типа «Почти сделано», «Сделано, но..» приравниваются к «Я не сделал»" - очевидно, бред, так как почти сделано - значит "почти сделано" и эта оценка точнее всего описывает реальное положение дел, сводить к "не сделал" нельзя.
Максимизация функции полезности через варьирование параметров - тогда может помочь уже готовое решение - симплекс-метод. На питоне есть имплементации. Тогда задачка упрощается и нужно только написать теоретико-игровую оболочку. Однако тут нужно все-таки знать о какой теоретико-игровой модели речь. Я писал на питоне в магистратуре поиск равновесия по Нэшу в ромбовидной иерархической структуре и там для получения решения для 4 игроков (управляющий центр, два игрока по середине ромба и самый нижний игрок (в ромбе)) мне приходилось решать методом Монте-Карло, генерируя десятки и сотни тысяч случайных векторов для нескольких сотен решений ЗЛП симплекс-методом. Если интересно - https://dspace.spbu.ru/handle/11701/32556 Поэтому сначала лучше рассмотреть небольшой размер задачи вашей модели и посмотреть как получится найти решение для нее.
Сам являюсь разработчиком пет-проекта по решениям теории игр на Ruby. Есть ряд вопросов к требованиям: - пункт 7 говорит о работе с базой для вычисления стратегий и игр, что недостаточно обоснованно, пользователь вносит данные и просит отчет. Сами отчеты можно сохранять в базу - с данными результатами прогона. Зачем хранить промежуточные данные для расчетов, неясно, к тому же, с факториальной сложностью? Это может периодически класть базу. - 12 и 13 пункты явно нуждается в ограничении числа стратегий и игроков. Например, вычисление биномиальных коэффициентов Вектора Шепли невозможно для более, чем 171 игрока ввиду получения крайне малых для обработки чисел. Лучшей стратегий здесь была бы такая же проверка каждого решения на адекватную скорость и возможность получить решение в принципе. - по 14 пункту не понятно какой принцип оптимальности имеется ввиду - выбор в теории игр более чем огромен. - 16 пункт опять же крайне сложно реализовать, даже есть иметь ввиду что раундов будет меньше 1000 и игроков меньше 500. Интересен подход с характеристиками и созданиями отдельного класса для каждого игрока. Я рассматривал только одну характеристику - выигрыш (вне бизнес-логики или обоснования), что позволило требовать от пользователей hash с регистро-независимыми уникальными ключами как названию коалиции: {a: 1, b: 2, ab:3}. В том числе для одноэлементных коалиций. Но в вашей реализации эти характеристики можно использовать в том числе для раздела "игр на сетях" - в зависимости от данной связи объектов, описанных через их атрибуты, что очень интересно. Хотелось бы увидеть продолжение проекта.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Вы другими словами изобрели заново идеалистическую концепцию Мира как Воли и Представления Шопенгауэра. Прежде чем писать о чем-то философском, ознакомьтесь, пожалуйста, с базовыми понятиями философии.
Ужасный текст, совершенно не по правилам хабра
За no-code решения бизнес может предложить только no-money зарплату)
Хорошие, универсальные в целом советы. Добавил бы только про необходимость на опыте доказывать свою точку зрения, так как даже лиды иногда бывают не правы (редко, конечно). Чаще всего пригождается навык оценки задач и его доказательства перед ПМ. С этим навыком и сам в голове составляешь план на задачу и решать ее проще.
"Подрывают авторитет руководителей и собственника компании, т.к. складывается впечатление, что они принимают неэффективные решения." То есть это не владельцы с манагерами придумали странный подход и всех переучивают, и их решение может быть неэффективным, а "впечатление". А несогласных просто уволить - если подкупить и пригрозить контролем не помогает. Отличная статья! Правда я бы добавил еще как вариант плеть и рудники, но до такого уровня раболепства еще надо добраться.
Вы просто из головы тащите какие-то ложные аналогии. Что в статье ложная, что тут. Так в статье про собаку, утку и охотника вообще иначе было написано. Скажу только, что задачи - не утки, разработчик - не ваш пёс, что тащит по первому указанию, а вы не охотник. В метафоре про собаку все по-идиотски просто, (получил приказ - принёс утку). Но жизнь сложнее, сори. Ответ на ваш вопрос: решил заняться своими делами - значит они важнее, решил сделать задачу - значит было решение разработчика её сделать. Если работа не сделана, а он обещал, то это или ошибка, что взяли человека, или неправильно объяснили как и что сделать. Ещё задавайте простые банальные вопросы, прошу)
Чтобы контролировать работу приложения в целом, мыслить его в максимально большом масштабе. Связываться почти со всеми в команде. Это не тот, кто мыслит "идеального сотрудника" или тот, кто командует взять "утку". Условно, все более-менее нормальные лиды не мыслят себя манагерами, а разработчиками или тестерами.
Лидер должен быть у племени. В разработке ПО должны быть финансовые ресурсы, специалисты, окружение и техника. Когда лидеров нет, есть продуктивность и каждый делает свою работу.
Никаких "руководителей" быть вовсе не должно - каждый в команде выполняет свою часть задач. Менеджер - планирование, коммуникации между сотрудниками и с клиентами, разработчик делает софт, тестировщик обеспечивает качество. Вопрос про идеального сотрудника эквивалент вопроса идеального раба у древнегреческих философов. Почему история про собаку и охотника идиотская? Просто у вас нет критерия, что является неразрешимой задачей (охотник сказал собаке достать Луну), и я уж молчу, что вообще-то идеальный сотрудник - это не тот, кто сделает вашу задачу качественно (даже про срок нет разговора, значит второй ваш пример про Артура и есть ответ на проблему статьи). Это человек, а не машина (возвращаемся к аллегории раба). Надеюсь никогда не буду с вами работать)
Очевидно, очередной неадекватный эйчар-иинструмент, который по определению не способен отразить обладание скиллами и легко служит способом не повышать зп или не выдавать премию. Во-первых, коллеги чаще всего не способны адекватно оценить своего коллегу по фрагментам его знаний (код ревью не в счет, элементарный рандом при планировании). В моем случае все бэкендеры всегда ставили оценки максимум или 4 из 5 во всех сферах. Да и по приведенным примерам надо чуть ли не сессию каждому разрабу оформлять. Во-вторых, коллегам не всегда выгодно честно отвечать на поставленные тематики (когнитивные искажения, привет). Чаще всего именно тимлид отвечает честно и по делу, потому что конечное решение за ним. В-третьих, результаты любых оценок можно исказить так, как угодно, веса то устанавливаются теми, кто решает вопрос о повышении :)
Получается, что если разработчик с командой запустит новый сервис, но разработчики недостаточно хорошо его оценили, то повышения и премии ему не видать, даже если новый сервис приносит миллионы компании. В целом, неясно зачем нужно было это приложение, почему нет прозрачной работы с весами и где гарантии честности. Excel по духу все-таки близок.
В подавляющем числе проектов и по практикам мету не используют и правильно делают. Класс - основа для проектирования и работы самого языка, осмысленные данные такого типа упаковывать в него логично по содержанию. 4 пункт явно очень спорный, отбраковывать кандидатов из-за немного другого подхода, который вам не нравится, но не является ошибкой ни в коем случае - самодурство.
Текст очевидного максималиста. Кабан Кабаныч будет рад всему что здесь перечислено. Например, "Выражения типа «Почти сделано», «Сделано, но..» приравниваются к «Я не сделал»" - очевидно, бред, так как почти сделано - значит "почти сделано" и эта оценка точнее всего описывает реальное положение дел, сводить к "не сделал" нельзя.
Максимизация функции полезности через варьирование параметров - тогда может помочь уже готовое решение - симплекс-метод. На питоне есть имплементации. Тогда задачка упрощается и нужно только написать теоретико-игровую оболочку. Однако тут нужно все-таки знать о какой теоретико-игровой модели речь. Я писал на питоне в магистратуре поиск равновесия по Нэшу в ромбовидной иерархической структуре и там для получения решения для 4 игроков (управляющий центр, два игрока по середине ромба и самый нижний игрок (в ромбе)) мне приходилось решать методом Монте-Карло, генерируя десятки и сотни тысяч случайных векторов для нескольких сотен решений ЗЛП симплекс-методом. Если интересно - https://dspace.spbu.ru/handle/11701/32556
Поэтому сначала лучше рассмотреть небольшой размер задачи вашей модели и посмотреть как получится найти решение для нее.
Сам являюсь разработчиком пет-проекта по решениям теории игр на Ruby. Есть ряд вопросов к требованиям:
- пункт 7 говорит о работе с базой для вычисления стратегий и игр, что недостаточно обоснованно, пользователь вносит данные и просит отчет. Сами отчеты можно сохранять в базу - с данными результатами прогона. Зачем хранить промежуточные данные для расчетов, неясно, к тому же, с факториальной сложностью? Это может периодически класть базу.
- 12 и 13 пункты явно нуждается в ограничении числа стратегий и игроков. Например, вычисление биномиальных коэффициентов Вектора Шепли невозможно для более, чем 171 игрока ввиду получения крайне малых для обработки чисел. Лучшей стратегий здесь была бы такая же проверка каждого решения на адекватную скорость и возможность получить решение в принципе.
- по 14 пункту не понятно какой принцип оптимальности имеется ввиду - выбор в теории игр более чем огромен.
- 16 пункт опять же крайне сложно реализовать, даже есть иметь ввиду что раундов будет меньше 1000 и игроков меньше 500.
Интересен подход с характеристиками и созданиями отдельного класса для каждого игрока. Я рассматривал только одну характеристику - выигрыш (вне бизнес-логики или обоснования), что позволило требовать от пользователей hash с регистро-независимыми уникальными ключами как названию коалиции: {a: 1, b: 2, ab:3}. В том числе для одноэлементных коалиций. Но в вашей реализации эти характеристики можно использовать в том числе для раздела "игр на сетях" - в зависимости от данной связи объектов, описанных через их атрибуты, что очень интересно. Хотелось бы увидеть продолжение проекта.