Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи.
И понятно почему так произошло.
ТОС это как раз не про то, чтобы найти ограничение и быстрее его расшить. В этом и автор статьи ошибается.
ТОС говорит, что найдя ограничение мы должны всю систему подчинить ему. И вот если и этого не хватает, то только потом расшиваем ограничение.
Если это разраб, то:
Задачи к нему должны приходить максимально продуманные, так чтобы он не тратил время на переуточнение запроса
Задачи ему надо отдавать не всякие, а только те, что принесут максимальную прибыль за единицу времени работы разраба. Это называется проход на ограничение: прибыль минус полностью переменные затраты на эту задачу (в IT обычно это 0, так как нет прямых затрат на задачу, разве что мы можем покупать под каждый заказ стороннюю лицензию, тогда её и вычитаем), разницу разделить на время работы ограничения
Надо убедиться, что разраб не занимается работой, которая не приносит нам профит: всякие скрипты для других - пусть пишут другие, данные для аналитиков или ещё кого-то - тоже пусть собирают другие и т.п.
Если сделать так, что путём изменения способа работы, то мы получим максимум прибыли минимальными затратами. А расшивать ограничение - это часто большие траты.
Бессмысленны и вредны привязки любых показателей к премиям и зряплате.
Именно тут система поменяет своё поведение, чтобы наиболее эффективно получать эти премии. Только работодатель надеется, что люди будут делать эффективно для работодателя.
А сами по себе показатели важны, чтобы искать области для изменений и оценивать их успешность.
Кому писать авто тесты - может быть вопросом узкого звена в цепи разработки.
У нас это тестировщики. И поэтому автотесты пишут разработчики.
Но фраза про то, что писать автотесты на свой код плохо, натолкнула меня на мысль, то автотесты к функционалу, реализованного одним разработчиком, должен писать другой. Это ещё будет способствовать узнаванию функционала.
Только ведь не важно что будет (swagger, WSDL и т.п.) если проблема в:
Перегенерация клиентов на любое изменение апи, ..., отсутствие поддержки предыдущих версий API
У нас приняты правила:
мажорная версия АПИ в урле
в рамках мажорной версии данной функции обратная совместимость обязательна
параметры, которые добавляются в запросы в рамках минорных версий, не могут быть обязательными
клиенты и серверы толерантны к данным, которые не оговорены в АПИ
Таким образом, из-за пункта 1 любое несовместимое изменение просто добавляется в версию выше по другому урлу. Плюс: клиентскую часть не требуется перегенерировать с выпученными глазами. Плюс: Не требуется проводить синхронных установок на ребочку и т.д.
Из-за пунктов 2 и 3, при поднятии минорной версии, клиентов не требуется перегенерировать, если им не требуется новые параметры. Плюс: можно продолжать работать на старых клиентах и всё должно работать.
Плюс: из-за пункта 4 любой из участников может обновиться независимо от других. Если у клиент не использует новые функции, то он может уехать на рабочку раньше сервера и это не сломает обмен. Может сервер уехать на рабочку раньше клиентов и новые параметры возвращаемых значений не сломают клиента.
Из минусов:
программистам работать (а точнее думать) приходится.
Надо держать совместимость старых версий до какого-то срока (обычно полгода-год). Надо писать код, который не уйдёт в разнос, если появились какие-то данные или неожиданные возвращаемые значения.
нужна строгая дисциплина. Ну тут ревьюверы помогут, ибо если они пропустят изменение, нарушающее правила, то им же и придётся судорожно обновлять все системы
И понятно почему так произошло.
ТОС это как раз не про то, чтобы найти ограничение и быстрее его расшить. В этом и автор статьи ошибается.
ТОС говорит, что найдя ограничение мы должны всю систему подчинить ему. И вот если и этого не хватает, то только потом расшиваем ограничение.
Если это разраб, то:
Задачи к нему должны приходить максимально продуманные, так чтобы он не тратил время на переуточнение запроса
Задачи ему надо отдавать не всякие, а только те, что принесут максимальную прибыль за единицу времени работы разраба. Это называется проход на ограничение: прибыль минус полностью переменные затраты на эту задачу (в IT обычно это 0, так как нет прямых затрат на задачу, разве что мы можем покупать под каждый заказ стороннюю лицензию, тогда её и вычитаем), разницу разделить на время работы ограничения
Надо убедиться, что разраб не занимается работой, которая не приносит нам профит: всякие скрипты для других - пусть пишут другие, данные для аналитиков или ещё кого-то - тоже пусть собирают другие и т.п.
Если сделать так, что путём изменения способа работы, то мы получим максимум прибыли минимальными затратами. А расшивать ограничение - это часто большие траты.
KPI важны и полезны.
Бессмысленны и вредны привязки любых показателей к премиям и зряплате.
Именно тут система поменяет своё поведение, чтобы наиболее эффективно получать эти премии. Только работодатель надеется, что люди будут делать эффективно для работодателя.
А сами по себе показатели важны, чтобы искать области для изменений и оценивать их успешность.
Кому писать авто тесты - может быть вопросом узкого звена в цепи разработки.
У нас это тестировщики. И поэтому автотесты пишут разработчики.
Но фраза про то, что писать автотесты на свой код плохо, натолкнула меня на мысль, то автотесты к функционалу, реализованного одним разработчиком, должен писать другой. Это ещё будет способствовать узнаванию функционала.
Спасибо за идею.
Только ведь не важно что будет (swagger, WSDL и т.п.) если проблема в:
У нас приняты правила:
Таким образом, из-за пункта 1 любое несовместимое изменение просто добавляется в версию выше по другому урлу. Плюс: клиентскую часть не требуется перегенерировать с выпученными глазами. Плюс: Не требуется проводить синхронных установок на ребочку и т.д.
Из-за пунктов 2 и 3, при поднятии минорной версии, клиентов не требуется перегенерировать, если им не требуется новые параметры. Плюс: можно продолжать работать на старых клиентах и всё должно работать.
Плюс: из-за пункта 4 любой из участников может обновиться независимо от других. Если у клиент не использует новые функции, то он может уехать на рабочку раньше сервера и это не сломает обмен. Может сервер уехать на рабочку раньше клиентов и новые параметры возвращаемых значений не сломают клиента.
Из минусов:
Надо держать совместимость старых версий до какого-то срока (обычно полгода-год). Надо писать код, который не уйдёт в разнос, если появились какие-то данные или неожиданные возвращаемые значения.