Хороший ОРМ (для дотнета, например, linq2db, бывший bl toolkit) — библиотека, плохой — фреймворк (пример — первые версии entity framework, linq 2 sql).
А вот продажникам урежут зарплаты или уберут премии. Вопрос: за что?
Сорри, что отвечаю на каждую вашу реплику.
Суть работы продажника и программиста разная. Внутренняя мотивация разная. Аналог продажника у программистов — это product owner, продакт-менеджер, и его доход (обычно премии) привязаны к продажам.
Программист же в продуктовой компании напрямую влиять на продукт не может, он делает то, что ему сказали делать на этой неделе. Сказали "все фиксим баги" — все сидим и фиксим, сказали воплощать обещания маркетологов — значит, не фиксим, добавляем новый функционал (а с ним и баги).
То есть, по сути, баги в продукте — это не вина программиста. Без багов разрабатывать невозможно (хотя можно выдавать код в среднем более качественный, но дороже), а стабильность продукта сильно зависит от времени на тестирование и починку ошибок.
Они страдают зависимостью от продукта. И конкретно в этом и заключается проблема. Почему только зарплата продажника зависит от качества продукта и того, как он продается, а других работников — нет?
Программисты лажают с фичами, маркетологи дают невыполнимые обещания, менеджеры ставят невыполнимые сроки, пользователи, гады, не хотят пользоваться.
Невозможно все контролировать, невозможно отвечать за все и все делать самому. Делегация и разделение — это суть бизнеса, и все работники должны это принимать и работать исходя из этого.
Лучше без KPI, если компания не жадная(% с продаж, например), а то можно увлечься и очень легко накидать таких KPI, что сотрудники начнут хакать эти самые KPI, сводя всю деятельность к «полезной», т.е. только той, которая улучшает показатели KPI.
Согласен. Главное не забыть, что задача KPI — это повышение эффективности компании, а не экономия по три копейки с сотрудника по каждому поводу.
Описание бизнес-процессов в формальном виде хорошая вещь...
Хорошая, но не всегда нужная. Делать бизнес-анализ и описание процессов без четкой цели бессмысленно. Нужна причина.
Обычные причины — это обучение новых сотрудников, налаживание управленческого учета (часто если есть подозрение, что некто очень хитрый перераспределяет блага в свою пользу).
Также описание и анализ бизнес-процессов нужны для автоматизации
Не уверен, что KPI и бизнес-процессы это одно и то же.
Бинес-процессы описывают "алгоритм" функионирования бизнеса: какие действия в каком случае кем совершаются, кто ответственный, что делать в случае "исключительных" ситуаций и т.п.
Формализация (описание) бизнес процессов в общем-то не предназначена для оценки или увеличения эффективности бизнеса (и отдельных людей), а больше для увеличения "прозрачности" и "ясности" каждого этапа, и выявления возможных "тупиковых ответвлений", не предусмотренных и не продуманных заранее.
Технически, конечно, компиляция (или интерпретация). Компьютеры пока не научились джаваскрипт исполнять непосредственно, поэтому, совсем без компиляции/интерпретации не обойтись, очевидно :)
Я имел ввиду компиляцию джаваскрипта перед запуском на Node.
На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый, галерный "аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.
В дотнете фреймворк — это джит-компилятор и рантайм. Остальное — это библиотеки.
Фреймворк вызывает ваш код, ваш код вызывает библиотеки.
Хороший ОРМ (для дотнета, например, linq2db, бывший bl toolkit) — библиотека, плохой — фреймворк (пример — первые версии entity framework, linq 2 sql).
Это вы зря, про простую задачу. DSL или строки с форматированием самое то.
Сорри, что отвечаю на каждую вашу реплику.
Суть работы продажника и программиста разная. Внутренняя мотивация разная. Аналог продажника у программистов — это product owner, продакт-менеджер, и его доход (обычно премии) привязаны к продажам.
Программист же в продуктовой компании напрямую влиять на продукт не может, он делает то, что ему сказали делать на этой неделе. Сказали "все фиксим баги" — все сидим и фиксим, сказали воплощать обещания маркетологов — значит, не фиксим, добавляем новый функционал (а с ним и баги).
То есть, по сути, баги в продукте — это не вина программиста. Без багов разрабатывать невозможно (хотя можно выдавать код в среднем более качественный, но дороже), а стабильность продукта сильно зависит от времени на тестирование и починку ошибок.
Потому что иначе он будет продавать плохо.
Программисты лажают с фичами, маркетологи дают невыполнимые обещания, менеджеры ставят невыполнимые сроки, пользователи, гады, не хотят пользоваться.
Невозможно все контролировать, невозможно отвечать за все и все делать самому. Делегация и разделение — это суть бизнеса, и все работники должны это принимать и работать исходя из этого.
Согласен. Главное не забыть, что задача KPI — это повышение эффективности компании, а не экономия по три копейки с сотрудника по каждому поводу.
Хорошая, но не всегда нужная. Делать бизнес-анализ и описание процессов без четкой цели бессмысленно. Нужна причина.
Обычные причины — это обучение новых сотрудников, налаживание управленческого учета (часто если есть подозрение, что некто очень хитрый перераспределяет блага в свою пользу).
Также описание и анализ бизнес-процессов нужны для автоматизации
Не уверен, что KPI и бизнес-процессы это одно и то же.
Бинес-процессы описывают "алгоритм" функионирования бизнеса: какие действия в каком случае кем совершаются, кто ответственный, что делать в случае "исключительных" ситуаций и т.п.
Формализация (описание) бизнес процессов в общем-то не предназначена для оценки или увеличения эффективности бизнеса (и отдельных людей), а больше для увеличения "прозрачности" и "ясности" каждого этапа, и выявления возможных "тупиковых ответвлений", не предусмотренных и не продуманных заранее.
Скажите, на каком-нибудь из приведенных вами сайтов можно заказать приложение за рассчитанную там цену?
Статья понравилась спасибо.
Ну как же, человек пришел за большими деньгами, а вы его работать заставляете. [sarcasm]
Вроде для Студии тоже экспериментировали с ReSharper Server, хз, чем закончилось.
Технически, конечно, компиляция (или интерпретация). Компьютеры пока не научились джаваскрипт исполнять непосредственно, поэтому, совсем без компиляции/интерпретации не обойтись, очевидно :)
Я имел ввиду компиляцию джаваскрипта перед запуском на Node.
Ну в плане возможностей языка, я думаю, из мейнстрима — C# один из лидеров.
По экосистеме и популярности — вы правы.
Да в том-то и дело, что хотелось бы без babel. Он, конечно, крутой, но все-таки отсутствие компиляции круче, чем самая крутая компиляция.
then после catch не правильно, если, конечно, не хотите попасть в оба.
Резолвить по тем же правилам, что и пути в
require. Сделали бы хоть простейшую поддержку в виде трансформации в require/module.exports.На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый,
галерный"аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.Немного уточню: митинги и дурацкие ритуалы можно привнести в любую методологию разработки, к сожалению.