Думаю, многим хабролюдям довелось побывать в роли человека-оркестра в таких самобытных конторках, где и программу разработать, самому же к ней инструкцию написать, установить у всех на ПК и далее активно принимать участие в разборе ситуаций «я тут весь день потратила, а оно куда-то всё пропало», меняя между делом картриджи и вытаскивая бумагу в (из) принтерах(-ов).
Противоположность этому – работа в крупных компаниях с высоким уровнем зрелости процессов (типа CMMI 3 и выше), где специалист с некоторого момента начинает ощущать себя мелким винтиком в большом механизме, выполняющим кусок работы, не особо понимая, для чего это, кто это будет эксплуатировать, с какими проблемами сталкивается сейчас и будет сталкиваться после внедрения программного продукта.
Где же золотая середина, баланс базара и матрицы? Навряд ли в обозримом будущем появится однозначный универсальный ответ на этот вопрос. Но есть принципы планирования и совершенствования совмещения труда на отдельно взятом производстве (организации), которые и представлены в данной статье с упором на сферу разработки программного обеспечения.
Мне поисковики на запросы типа «совмещение труда» выдают в топе всевозможные статьи для кадровиков, объясняющих, каким образом правильно оформить совмещение труда, не нарушая Трудовой кодекс РФ. Мне же хочется в данной статье раскрыть тему с позиции экономики труда, организации производственных отношений, планирования разделения и кооперации труда на предприятии.
После прочтения прошу всех пройти опрос.
Начнём с того, что многие, уверен, и так знали до сих пор, но не рассматривали под углом разделения и кооперации труда.
В своей знаменитой книге «Мифический человеко-месяц» Фредерик Брукс приводит много статистических данных и их обобщений из своего опыта работы над проектами в IBM в 60-х, 70-х и 80-х годах прошлого века по созданию операционных систем, системного и прикладного ПО. Среди прочего он рассматривает случаи совместной работы членов команды над полностью разделимыми задачами (идеальный вариант, который он позиционирует как «мифический»), полностью неразделимыми задачами (например, наличие единственного специалиста в некой области, без результата труда которого другие не могут приступить к своей работе, эдакий критический путь в сетевом графике), а также промежуточный случай – разделимая задача, требующая обмена данными между членами команды.
Для последнего варианта он приводит формулу n ? (n — 1) / 2 – число связей, когда требуется обмен данными между каждым участником. Это, на самом деле, упрощение формулы числа сочетаний из n по 2 из комбинаторики:
В данном случае k=2, получаем n ? (n — 1) ? (n – 2)! / (2 ? (n — 2)!) = n ? (n — 1) / 2. Т.е. при 5 человеках в команде получаем возможных 10 связей, для 6 – 15, 10 – 45. А вообще возможное число групп коммуникаций – 2n.
Конечно, методологическая мысль в области разработки ПО не дремлет и направлена, среди прочего, на то, чтобы снизить число связей, исключить дублирование коммуникаций за счёт объединения реципиентов в группы и т.д. Но в любом случае время на коммуникации внутри команды берётся за счёт рабочего времени (ну или внеурочного, чего уж там). Причём чем больше членов команды, тем неизбежно будет расти время на коммуникации, для демонстрации чего Брукс приводит график зависимости продолжительности условного фиксированного проекта от числа участников:
Рис. 1. Условный график зависимости длительности проекта от размера команды
Здесь же можно вспомнить фразу: «Восемь человек справляются с работой десяти лучше, чем двенадцать».
Очевидно, на мой взгляд, то, что за счёт совмещения трудовых функций разных специалистов можно снизить число n, а следовательно – и количество коммуникаций. Подчеркну, что здесь я имею в виду работу в одной упряжке разноплановых специалистов (разработчик, тестировщик, аналитик, системный архитектор). Работа одного за двух программистов – это тема совсем другого обсуждения.
Тем не менее, сильно яснее не становится, что именно можно делать при использовании совмещения труда, а что – нет. Тут возникает желание обратиться к советским изысканиям: хотя научную организацию труда (НОТ) придумали не у нас и даже не Советы первыми начали заниматься в нашей стране, но именно при советской власти НОТ получила поддержку на правительственном и идеологическом уровне уже с первых лет существования молодого советского государства.
Действительно, в первой половине 1980-х ряд отраслевых НИИ в рамках соответствующей программы подготовили по единой методике рекомендации «развития и повышения эффективности совмещения профессий (должностей) и функций» по отдельным отраслям (раз, два, три, четыре, пять, шесть, семь, восемь …). Брошюру для работников транспорта я оцифровал (без приложений), в полной уверенности, что никаких прав я не нарушу, хотя НИИ Труда всё ещё существует и немного даже функционирует. Я рекомендую ознакомиться в обязательном порядке с этой работой всем, кто интересуется организацией труда вне зависимости от сферы деятельности.
Хотя методических рекомендаций по ИТ-специалистам разработано не было, основные положения мы без труда можем перенести и на сферу разработки ПО, т.к. они практически слово в слово дублируются во всех упомянутых выше методических рекомендациях, и не потеряли своей актуальности и по сей день, чего не скажешь о конкретных нормативах, представленных в приложениях. Тем не менее здесь вы можете найти Приложение №2 и начало приложения №3 для работы по строительству.
Итак, ниже представлены предпосылки и условия внедрения совмещения профессий и функций, а также прочие общие положения.
Предпосылки:
Совмещение профессий (должностей) разрешается, как правило, в пределах той категории персонала, к которой относится данный работник (рабочие, инженерно-технические работники, служащие и др.).
Условия:
Здесь я просто процитирую кусками:
По итогам этого анализа определяется часть сменного времени, свободного от выполнения работником трудовых операций по его основной профессии (должности), — tсовм. Этот расчет производится по следующей формуле:
tсовм = Тобщ — (tосн + tотд),
где Тобщ — общий фонд рабочего времени;
tосн — время работы но основной профессии (должности), включая вес его элементы;
tотд — время, регламентированного отдыха.
Ещё дословное цитирование:
Хочу от себя особо подчеркнуть наиболее важные, на мой взгляд, идеи:
Как было сказано чуть выше, здесь можно ознакомиться с примером проектирования совмещения профессий в комплексной бригаде монтажников строительных конструкций (ВНИПИ труда в строительстве Госстроя СССР, 1983г.). Там вы можете обратить внимание на отсылку к Приложению №1, где приводятся допустимые варианты совмещения профессий в строительстве.
Но что же делать нам, разработчикам софта? У нас есть «Основы Microsoft Solution Framework» Майкла Тёрнера (я использовал русскоязычное издание – 2008г.).
MSF оперирует такими понятиями как группы представителей, которые нам устойчиво напоминают профессии в разработке софта. Единственное, что сбивает с толку, – это «Управление продуктом» и «Управление программой». Нам здесь для простоты можно считать оби эти группы «Управлением проектов», но первую с уклоном в бизнесовые интересы, а вторую – в ИТ-шные. А «Удовлетворение пользователей» – это техподдержка. Ниже приведена таблица допустимости вхождения специалистов в пару групп представителей. Здесь может быть 3 варианта: допустимо, нежелательно или рискованно.
Таблица 1. Допустимость одновременной принадлежности отдельно взятого специалиста ко 2 ролевым группам
Microsoft при составлении этой таблицы отталкивается от принципа конфликта интересов. Например, разработчик заинтересован в скорейшей передаче продукта в эксплуатацию, тестировщик – в обнаружении и устранении всех ошибок, техподдержка – в присутствии важных функциональных особенностей. Ниже на схеме представлено распределение ролей команды из 3 человек с учётом рекомендаций MSF.
Рис. 2. Пример распределение ролей в команде из 3 человек в MSF
Будем также надеяться, что корпорация провела исследования на реальных проектах работоспособность предложенной модели.
Давайте снова вернёмся к примеру проектирования совмещения профессий в комплексной бригаде монтажников строительных конструкций. Обратите внимание, что объемы трудозатрат фиксированы, что не учитывает неравномерность нагрузок по различным специальностям в ходе продвижения работ по проекту.
Рис. 3. Неравномерность распределения работ по отдельным функциональным областям в ходе продвижения проекта
По этой причине упомянутый выше метод фотографии рабочего дня или даже смены плохо подходит для области программной инженерии, если только это не техподдержка или конвейерная разработка минипроектов, где можно наблюдать циклические, повторяющиеся работы.
Поэтому трудозатраты предлагается рассматривать отдельно на каждом управленческом отрезке времени: неделе, итерации, спринте. В результате требуется составить матрицу Cij – трудозатраты по i-й специальности (или развернуто до отдельного специалиста) в j-й отрезок времени. При этом при планировании совмещения трудовых функций, основываясь на описанных выше принципах, следует удостовериться, что ни на одном из временных отрезков сумма трудозатрат по совмещаемым специальностям не превышает фонд рабочего времени.
Например, пусть T – фонд рабочего времени 1 специалиста на каждом временном отрезке проекта. Специалиста k планируется привлекать к выполнению обязанностей специалиста r. Тогда T >= MAXj=1..n(Ckj + Crj).
Просто процитирую, как есть.
Правда, в реальной жизни всё это достаточно легко обходится работодателем за счёт пункта в должностных обязанностях, на которые ссылается трудовой договор сотрудника: «и другие поручения руководства». Поэтому формально в трудовой договор впихнуто всё на свете.
Рядом определена статья ТК РФ, Статья 60.1. Работа по совместительству. Совместительством называется наличие у работника более 1 трудового договора с работодателем. Этому вопросу посвящена Глава 44.
Итак, совмещение профессий может положительно сказаться на снижении внутрикомандных коммуникативных издержек, но необходимыми условиями являются:
При этом при изыскании временных резервов должны учитываться пиковые нагрузки на основную и совмещаемую профессии. Стимулом для работников при привлечении к выполнению функциональных обязанностей других должностей должны быть повышение содержательности труда и доплаты.
На этом считать полностью раскрытым вопрос совмещения труда, разумеется, нельзя. Многое осталось за рамками, например:
Причина тому – недостаток объективных данных.
Кстати, по поводу полноты и объективности MSF у меня есть сомнения. И хотя я осознаю ущербность опросов перед замерами, но всё же это лучше, чем ничего, поэтому прошу всех принять участие в опросе. Его промежуточные результаты вы сами сможете увидеть самостоятельно по его прохождении. Если данная тема вызовет интерес и/или будут интересные результаты опроса, то обещаю написать продолжение данной статьи.
Противоположность этому – работа в крупных компаниях с высоким уровнем зрелости процессов (типа CMMI 3 и выше), где специалист с некоторого момента начинает ощущать себя мелким винтиком в большом механизме, выполняющим кусок работы, не особо понимая, для чего это, кто это будет эксплуатировать, с какими проблемами сталкивается сейчас и будет сталкиваться после внедрения программного продукта.
Где же золотая середина, баланс базара и матрицы? Навряд ли в обозримом будущем появится однозначный универсальный ответ на этот вопрос. Но есть принципы планирования и совершенствования совмещения труда на отдельно взятом производстве (организации), которые и представлены в данной статье с упором на сферу разработки программного обеспечения.
Мне поисковики на запросы типа «совмещение труда» выдают в топе всевозможные статьи для кадровиков, объясняющих, каким образом правильно оформить совмещение труда, не нарушая Трудовой кодекс РФ. Мне же хочется в данной статье раскрыть тему с позиции экономики труда, организации производственных отношений, планирования разделения и кооперации труда на предприятии.
После прочтения прошу всех пройти опрос.
Формула числа связей в команде
Начнём с того, что многие, уверен, и так знали до сих пор, но не рассматривали под углом разделения и кооперации труда.
В своей знаменитой книге «Мифический человеко-месяц» Фредерик Брукс приводит много статистических данных и их обобщений из своего опыта работы над проектами в IBM в 60-х, 70-х и 80-х годах прошлого века по созданию операционных систем, системного и прикладного ПО. Среди прочего он рассматривает случаи совместной работы членов команды над полностью разделимыми задачами (идеальный вариант, который он позиционирует как «мифический»), полностью неразделимыми задачами (например, наличие единственного специалиста в некой области, без результата труда которого другие не могут приступить к своей работе, эдакий критический путь в сетевом графике), а также промежуточный случай – разделимая задача, требующая обмена данными между членами команды.
Для последнего варианта он приводит формулу n ? (n — 1) / 2 – число связей, когда требуется обмен данными между каждым участником. Это, на самом деле, упрощение формулы числа сочетаний из n по 2 из комбинаторики:
В данном случае k=2, получаем n ? (n — 1) ? (n – 2)! / (2 ? (n — 2)!) = n ? (n — 1) / 2. Т.е. при 5 человеках в команде получаем возможных 10 связей, для 6 – 15, 10 – 45. А вообще возможное число групп коммуникаций – 2n.
Конечно, методологическая мысль в области разработки ПО не дремлет и направлена, среди прочего, на то, чтобы снизить число связей, исключить дублирование коммуникаций за счёт объединения реципиентов в группы и т.д. Но в любом случае время на коммуникации внутри команды берётся за счёт рабочего времени (ну или внеурочного, чего уж там). Причём чем больше членов команды, тем неизбежно будет расти время на коммуникации, для демонстрации чего Брукс приводит график зависимости продолжительности условного фиксированного проекта от числа участников:
Рис. 1. Условный график зависимости длительности проекта от размера команды
Здесь же можно вспомнить фразу: «Восемь человек справляются с работой десяти лучше, чем двенадцать».
Очевидно, на мой взгляд, то, что за счёт совмещения трудовых функций разных специалистов можно снизить число n, а следовательно – и количество коммуникаций. Подчеркну, что здесь я имею в виду работу в одной упряжке разноплановых специалистов (разработчик, тестировщик, аналитик, системный архитектор). Работа одного за двух программистов – это тема совсем другого обсуждения.
За нас уже подумали
Тем не менее, сильно яснее не становится, что именно можно делать при использовании совмещения труда, а что – нет. Тут возникает желание обратиться к советским изысканиям: хотя научную организацию труда (НОТ) придумали не у нас и даже не Советы первыми начали заниматься в нашей стране, но именно при советской власти НОТ получила поддержку на правительственном и идеологическом уровне уже с первых лет существования молодого советского государства.
Действительно, в первой половине 1980-х ряд отраслевых НИИ в рамках соответствующей программы подготовили по единой методике рекомендации «развития и повышения эффективности совмещения профессий (должностей) и функций» по отдельным отраслям (раз, два, три, четыре, пять, шесть, семь, восемь …). Брошюру для работников транспорта я оцифровал (без приложений), в полной уверенности, что никаких прав я не нарушу, хотя НИИ Труда всё ещё существует и немного даже функционирует. Я рекомендую ознакомиться в обязательном порядке с этой работой всем, кто интересуется организацией труда вне зависимости от сферы деятельности.
Хотя методических рекомендаций по ИТ-специалистам разработано не было, основные положения мы без труда можем перенести и на сферу разработки ПО, т.к. они практически слово в слово дублируются во всех упомянутых выше методических рекомендациях, и не потеряли своей актуальности и по сей день, чего не скажешь о конкретных нормативах, представленных в приложениях. Тем не менее здесь вы можете найти Приложение №2 и начало приложения №3 для работы по строительству.
Итак, ниже представлены предпосылки и условия внедрения совмещения профессий и функций, а также прочие общие положения.
Предпосылки:
- ввод в эксплуатацию новых <производственных> средств, оборудованных средствами автоматизации основных производственных процессов по их обслуживанию и управлению;
- совершенствование разделения и кооперации труда;
- развитие <командных> форм организации труда;
- повышение уровня организации трудовых процессов;
- объединение узкоспециализированных профессий в одну, более широкого профиля.
Совмещение профессий (должностей) разрешается, как правило, в пределах той категории персонала, к которой относится данный работник (рабочие, инженерно-технические работники, служащие и др.).
Условия:
- обусловленное технологическими особенностями производственных процессов неполное использование работником регламентированного фонда его рабочего времени за смену (месяц);
- технологическая общность выполняемых работ (операций, приемов) и единство конечной продукции (работы);
- возможность сочетания во времени и территориально выполнения производственных операций по основной и совмещаемой профессии;
- уровень и диапазон квалификации работника и возможность успешного освоения им профессиональных знаний и навыков по профессии, намечаемой для совмещения.
Здесь я просто процитирую кусками:
Для объективной и всесторонней оценки вариантов совмещения и определения степени занятости работника по основной и совмещаемой профессии (должности) необходимо учитывать специфические особенности трудовых процессов.
Определение фактической занятости рабочих производится на основе проводимых непосредственно на рабочих местах, фотографий рабочего дня (смены). Количество этих наблюдений (фотографий рабочего дня) зависит от степени сложности изучаемых технологических процессов. Результаты наблюдений тщательно анализируются и должны обеспечить Достоверные данные о фактической загрузке рабочего по, его основной профессии (должности).
По итогам этого анализа определяется часть сменного времени, свободного от выполнения работником трудовых операций по его основной профессии (должности), — tсовм. Этот расчет производится по следующей формуле:
tсовм = Тобщ — (tосн + tотд),
где Тобщ — общий фонд рабочего времени;
tосн — время работы но основной профессии (должности), включая вес его элементы;
tотд — время, регламентированного отдыха.
Ещё дословное цитирование:
При расчёте времени, возможного для использования по совмещаемой профессии (должности), очень важно исследовать продолжительность и периодичность периодов свободного времени по основной профессии (должности), так как в ряде случаев именно это определяет эффективность совмещения профессий (должностей).
При этом следует стремиться к тому, чтобы намечаемое совмещение профессий (должностей) повышало содержательность и привлекательность труда. В связи с этим не рекомендуется совмещать трудовые операции, выполняемые квалифицированными рабочими, с работой подсобного характера (уборка, подноска и т. д.). Необходимо также иметь в виду, что дополнительные нагрузки, возникающие при совмещении профессий (должностей), допустимы только до определенного уровня утомления работника.
Важнейшей предпосылкой дальнейшего развития совмещения профессий (должностей) является повышение эффективности его поощрения, которое должно быть нацелено на развитие инициативы работников транспорта, высокий производительный труд по основной и совмещаемой профессии (должности).
При высвобождении численности работников по сравнению с нормативами на доплаты за совмещение профессий может направляться до 70% экономии фонда заработной платы.
Хочу от себя особо подчеркнуть наиболее важные, на мой взгляд, идеи:
- Совмещение трудовых функций возможно при обязательном условии наличия достаточного свободного времени в рабочее время. Причиной наличия свободного времени может являться как следствием производственно-технологических особенностей, так и совершенствование организации труда, внедрение новых технологий и инструментов, повышение квалификации специалистов.
- Совмещение трудовых функций должно повышать привлекательность и содержательность труда.
- Совмещение трудовых функций должно стимулироваться материально. В зависимости от сложности совмещаемой работы и её продолжительности размер надбавки может достигать 50% от основного оклада.
- Несмотря на увеличение фонда оплаты труда отдельных работников за счёт доплат за совмещение, расходы предприятия должны уменьшиться за счёт снижения численности сотрудников.
Таблица допустимости свомещения
Как было сказано чуть выше, здесь можно ознакомиться с примером проектирования совмещения профессий в комплексной бригаде монтажников строительных конструкций (ВНИПИ труда в строительстве Госстроя СССР, 1983г.). Там вы можете обратить внимание на отсылку к Приложению №1, где приводятся допустимые варианты совмещения профессий в строительстве.
Но что же делать нам, разработчикам софта? У нас есть «Основы Microsoft Solution Framework» Майкла Тёрнера (я использовал русскоязычное издание – 2008г.).
MSF оперирует такими понятиями как группы представителей, которые нам устойчиво напоминают профессии в разработке софта. Единственное, что сбивает с толку, – это «Управление продуктом» и «Управление программой». Нам здесь для простоты можно считать оби эти группы «Управлением проектов», но первую с уклоном в бизнесовые интересы, а вторую – в ИТ-шные. А «Удовлетворение пользователей» – это техподдержка. Ниже приведена таблица допустимости вхождения специалистов в пару групп представителей. Здесь может быть 3 варианта: допустимо, нежелательно или рискованно.
Таблица 1. Допустимость одновременной принадлежности отдельно взятого специалиста ко 2 ролевым группам
Microsoft при составлении этой таблицы отталкивается от принципа конфликта интересов. Например, разработчик заинтересован в скорейшей передаче продукта в эксплуатацию, тестировщик – в обнаружении и устранении всех ошибок, техподдержка – в присутствии важных функциональных особенностей. Ниже на схеме представлено распределение ролей команды из 3 человек с учётом рекомендаций MSF.
Рис. 2. Пример распределение ролей в команде из 3 человек в MSF
Будем также надеяться, что корпорация провела исследования на реальных проектах работоспособность предложенной модели.
Неравномерность временного распределения нагрузки
Давайте снова вернёмся к примеру проектирования совмещения профессий в комплексной бригаде монтажников строительных конструкций. Обратите внимание, что объемы трудозатрат фиксированы, что не учитывает неравномерность нагрузок по различным специальностям в ходе продвижения работ по проекту.
Рис. 3. Неравномерность распределения работ по отдельным функциональным областям в ходе продвижения проекта
По этой причине упомянутый выше метод фотографии рабочего дня или даже смены плохо подходит для области программной инженерии, если только это не техподдержка или конвейерная разработка минипроектов, где можно наблюдать циклические, повторяющиеся работы.
Поэтому трудозатраты предлагается рассматривать отдельно на каждом управленческом отрезке времени: неделе, итерации, спринте. В результате требуется составить матрицу Cij – трудозатраты по i-й специальности (или развернуто до отдельного специалиста) в j-й отрезок времени. При этом при планировании совмещения трудовых функций, основываясь на описанных выше принципах, следует удостовериться, что ни на одном из временных отрезков сумма трудозатрат по совмещаемым специальностям не превышает фонд рабочего времени.
Например, пусть T – фонд рабочего времени 1 специалиста на каждом временном отрезке проекта. Специалиста k планируется привлекать к выполнению обязанностей специалиста r. Тогда T >= MAXj=1..n(Ckj + Crj).
Та самая статья Трудового кодекса
Просто процитирую, как есть.
ТК РФ, Статья 60.2. Совмещение профессий (должностей). Расширение зон обслуживания, увеличение объема работы. Исполнение обязанностей временно отсутствующего работника без освобождения от работы, определенной трудовым договором.
С письменного согласия работника ему может быть поручено выполнение в течение установленной продолжительности рабочего дня (смены) наряду с работой, определенной трудовым договором, дополнительной работы по другой или такой же профессии (должности) за дополнительную оплату (статья 151 настоящего Кодекса).
Поручаемая работнику дополнительная работа по другой профессии (должности) может осуществляться путем совмещения профессий (должностей). Поручаемая работнику дополнительная работа по такой же профессии (должности) может осуществляться путем расширения зон обслуживания, увеличения объема работ. Для исполнения обязанностей временно отсутствующего работника без освобождения от работы, определенной трудовым договором, работнику может быть поручена дополнительная работа как по другой, так и по такой же профессии (должности).
Срок, в течение которого работник будет выполнять дополнительную работу, ее содержание и объем устанавливаются работодателем с письменного согласия работника.
Работник имеет право досрочно отказаться от выполнения дополнительной работы, а работодатель — досрочно отменить поручение о ее выполнении, предупредив об этом другую сторону в письменной форме не позднее чем за три рабочих дня.
Правда, в реальной жизни всё это достаточно легко обходится работодателем за счёт пункта в должностных обязанностях, на которые ссылается трудовой договор сотрудника: «и другие поручения руководства». Поэтому формально в трудовой договор впихнуто всё на свете.
Рядом определена статья ТК РФ, Статья 60.1. Работа по совместительству. Совместительством называется наличие у работника более 1 трудового договора с работодателем. Этому вопросу посвящена Глава 44.
Заключение
Итак, совмещение профессий может положительно сказаться на снижении внутрикомандных коммуникативных издержек, но необходимыми условиями являются:
- Наличие достаточных временных резервов у специалистов основной професси
- Допустимость совмещения основной и совмещаемой профессий
- Обеспечение достаточной квалификации работника по совмещаемой профессии (обучение)
- Физическая возможность совмещения на конкретном производстве (время, место)
При этом при изыскании временных резервов должны учитываться пиковые нагрузки на основную и совмещаемую профессии. Стимулом для работников при привлечении к выполнению функциональных обязанностей других должностей должны быть повышение содержательности труда и доплаты.
На этом считать полностью раскрытым вопрос совмещения труда, разумеется, нельзя. Многое осталось за рамками, например:
- Технологическое совмещение трудовых функций в рамках одной должности (программирование на разных стеках технологий).
- Ограничение на среднесписочную численность работников предприятия (в РФ) для сохранения статуса среднего/малого предприятия и получения налоговых и прочих поблажек.
- Ограниченность в возможностях у небольших (по прибыли и человеческим ресурсам) компаний и их зависимость от «человеков-оркестров».
- Индивидуальные психофизические особенности работников, разделение и кооперация труда с учётом классификации психотипов.
- Преимущества и недостатки привлечения фрилансеров, аутсорсеров и прочих форм заёмного труда как способа межорганизационного разделения и кооперации труда.
Причина тому – недостаток объективных данных.
Кстати, по поводу полноты и объективности MSF у меня есть сомнения. И хотя я осознаю ущербность опросов перед замерами, но всё же это лучше, чем ничего, поэтому прошу всех принять участие в опросе. Его промежуточные результаты вы сами сможете увидеть самостоятельно по его прохождении. Если данная тема вызовет интерес и/или будут интересные результаты опроса, то обещаю написать продолжение данной статьи.
Комментарии (4)
samizdam
23.10.2017 22:05Неоднозначный вывод у MS о рискованности совмещения разработки и выпуска/эксплуатации. Понятно что конфликт интересов теоретически есть, но как же девопс и прочий инфрастракча эс код? На практике бывает более чем эффективно, когда разработка активно вовлечена в эти процессы.
neru Автор
24.10.2017 09:34Любую модель разграничения ответственности и ролей можно поставить под сомнение при желании. В том смысле, что для любой методологии всегда найдётся такая команда, которой эта самая методология не подойдёт.
Возможно, по прочтении статьи может сложиться впечатление о безальтернативности матрицы из MSF, но я не намеревался выставить это в таком свете.
virtual_hack2root
Очевидно, что специалист тех.поддержки и есть фактически тот самый стрелочник, первой линии поддержки и общения с пользователями и заказчиками, который вынужден в силу низкого "социального" технического ранга отдуваться за ошибки и просчеты руководства, отдела маркетинга, тестирования, в более глобально — отсутствия культуры принятия решений в бизнесе. Всегда так было, не видел ни одного линейного руководителя, менеджера, который бы признал себя ущербным руководителем и указал на свои просчеты. Такое поведение, самоанализ больше свойственно для уровня CEO, глав подразделений, высшего менеджмента. Потому что именно неумение работать в команде и неумение учиться на чужих ошибках и выдвигают этих личностей на руководящие посты, это "пояс безопасности", который приводит в конечном счете к краху компании или стартапа. Безосновательная убежденность в правильности стратегии найма и управления персоналом, обычно приводит к "эффекту горизонта", и как следствие сужению горизонта планирования, операционного простора и снижения показателей эффективности бизнеса. Ставка на сильных управленцев и бюрократов в сочетании со "специалистами широкого профиля" — этот тот фатальный сценарий, который тормозит развитие, в силу менталитета, почти 100% инновационных российских компаний. Специалисты широкого профиля вынуждены таковыми становиться из-за низкой корпоративной культуры, а именно — страха быть уволенными, потерять работу из-за каких-то субъективных факторов (коррупция, кумовство, потеря целей), неспособности и нежелания бизнеса брать узких специалистов, умеющих работать в команде, распределять ответственность равномерно, умения доверять решению других специалистов. То есть сама система человеческих отношений, государственная политика и отсутствие живой конкуренции приводят к росту ожиданий работодателей, заказчиков и самих работников. В реальной жизни с низкой социальной поддержкой, низкокачественным медицинским обслуживанием, высокой часовой нагрузкой (будем честными, кто работает по 8 часов?), психологической перегрузкой (тех.поддержка правой рукой, создание "инновационного" продукта — левой) специалисты все чаще оказываются ситуации когда приходится делать выбор между высокой заработной платой и доступным свободным временем. А в результате страдают целые сектора высоких технологий, без преувеличения.
neru Автор
Очень эмоционально получилось. Я так понял, что основная мысль здесь была про недооценку важности специалистов техподдержки? Согласен, что многие разработчики недооценивают на этапе проектирования и даже сдачи проекта важности наличия необходимого функционала у операторов, способов восприятия информации простыми пользователями, нет понимания целей, которые преследуют эти самые пользователи.
Но у нас в конторе для этого на этапе сдачи проекта привлекаются спецы и их начальники, ответственные за поддержку клиентов в затрагиваемой области. Они себе не враги и тупо не примут в эксплуатацию недоработанную систему.
Если же где-то это «прокатывает», то при честной и открытой игре они просто не выдержат конкуренции и покинут рынок в качестве самостоятельного игрока.