Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"... Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...
Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам. При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)
Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.
Сделайте всем исполнителям коммуникацию, что вы разрешаете списывать время постфактум так, как им это будет удобно.
Не совсем понял, что именно надо сделать всем исполнителям и как? Списывать время как удобно исполнителям? Это как? А если им удобно раз в неделю? Или раз в месяц? А как при таком подходе в случае превышения зафиксированной трудоемкости узнать сколько нужно времени на завершение задачи?
Обратная связь: Как количественно оценивать результаты работы отдельных сотрудников на программном проекте? Как и какие именно риски Вы оцениваете в ходе проекта (после инициации) и как их предупреждаете? Нужен ли тайм-трекинг на проекте? Как решаете проблемы неравномерности нагрузки на сотрудников? Вы ведёте учёт потерь на проекте? Если да, то каких именно и как?
Прочитать не смог, но осуждаю... Будь проще... По моему, я когда-то это уже слышал... И не раз... И что грустно, народу продолжают нравится такие выводы... Видимо, если так пойдет дальше, не за горами время, когда статьи будут содержать не больше двух-трех "ку"...
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах. Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
Что касается причин "трисоляриса", то я менее всего склонен рассматривать в качестве причин политику. Как меня учили когда-то, политика - всего лишь надстройка над исторически сложившейся экономической системой... То, что я осознал для себя на текущий момент, так это то, что не стоит бороться с мельницами, надо постараться выйти за рамки, понять истинные цели систем частью которых мы являемся и использовать их энергию в своих интересах людей, за которых я несу ответственность. Словить невидимый ветер. Не это ли основное предназначение руководителя? Некоторыми результатами экспериментов над живыми людьми, направленных на повышение эффективности управления IT-проектами, я иногда делюсь в своих статьях на Хабре. Если будет время, поглумитесь над ними как следует... ;)
Куда делись руководители с горящими глазами? Дискуссия скатилась в обсуждение проектных технологий и размера зарплаты PM... На мой взгляд причина совсем в другом... Уже не первый год и не в одной компании наблюдаю систему, которую один мой товарищ назвал "три круга". Первый круг - неприкасаемые - директор, его самые близкие замы и их родственники. В этом круге самая высокая зарплата... Второй круг - руководители отвечающие за результат работы. У этих нормальная зарплата по рынку и именно они руководят непосредственными исполнителями. Эти исполнители составляют третий круг и кадровый резерв для второго. Кроме ответственности за результат, основная задача второго круга - не допускать возмущенных исполнителей к лицам первого круга... Почему возмущенных? Потому, что зарплата третьего круга минимально возможная. Только чтобы проект не сдох. Иногда правда вынуждены держать экспертов... Но в принципе, все же знакомы с законом Паррето... Когда необходимо обеспечить минимально возможное качество, экспертов много не надо... Время жизни на первом и третьем круге, как правило значительно превышает время жизни на втором круге. С горящими глазами на втором круге долго не продержишься. По опыту, долго на втором круге держатся персонажи, которые умело превозносят руководство и не менее талантливо перекладывают все проблемы на третий круг. Кроме того, талантливый глупый руководитель второго круга может додуматься до того, что он может выполнять обязанности лиц первого круга... Таких вообще убивают сразу, пока маленькие... Благо заменить такого руководителя легко, на эти должности всегда конкурс. Поэтому долго тут держатся не самые умные, а самые преданные. Нет, преданные не проекту. Ну сами знаете кому... ;) Как мне кажется, тут лучше обсудить вопрос: в чем причина того, что во многих организациях сложилась такая система? Или у вас как то по другому?
Не соглашусь. Не надо всех учителей загонять под одну планку. На мой взгляд подавляющее БОЛЬШИНСТВО учителей, как раз наоборот - горячо переживают за своих учеников. Только вида не подают. Никто не хочет ссорится с любимчиками директора. В результате ложка яда, отравляет всю бочку меда. Только это не деготь. Этот яд не имеет ни запаха, ни вкуса, ни цвета. Здесь представлен инструмент который позволяет визуализировать влияние этого яда. Чтобы им не отравляли наших детей. КТО и как должен его устранить? На мой взгляд, инициировать очищение отравленного расписания, должны РОДИТЕЛИ - родительский комитет. Если ЛЮБОЙ родитель представит нам заявку на загрузку ВАШЕГО расписания в нашу систему - МЫ его загрузим и опубликуем с пометкой что это НЕОФИЦИАЛЬНАЯ ВЕРСИЯ расписания. Обращаю внимание, что мы заинтересованы в сотрудничестве с заинтересованными школами, чтобы работать с официальными версиями расписаний. После чего можно идти к директору разговаривать. Я предполагаю, что в этом случае найти взаимопонимание будет значительно проще. Только давить не надо. Директора школ тоже бывают разные. И у них, поверьте, проблем в нынешних условиях и так выше крыши... Однако отмечу, что доброе слово, подкрепленное объективным анализом расписания уроков на сайте aimfirst.ru действует гораздо убедительнее чем просто доброе слово... А ЧТО ДЕЛАТЬ потом? Про алгоритмы оптимизации, я планирую поговорить как нибудь в другой раз. В данном случае не предлагалось менять алгоритмы составления расписания. Сначала надо выработать объективные методы оценки. Может ничего менять не надо? А если менять, что именно менять? Понятно по Голдрату, что нужно устранять ограничения в системе. Однако, в каждом конкретном случае причины могут быть разными. Их надо выявить, опознать среди этих ограничений главное, снизить его влияние до минимума, после чего переформировать расписание (с использованием все того же алгоритма) и опять оценить его заново, выявить новые ограничения, опознать из них ОДНО главное - устранить и т.д. по циклу пока придем к невозможности устранения ограничений.
Тут надо хорошо подумать. Точно должна быть уменьшена дневная нагрузка чтобы количество уроков не превышало 6. Должен быть обеспечен контроль за нормами времени на выполнение домашних заданий, который не должен превышать 3 академических часов (15 академических часов в неделю). У ребенка должно быть время для реализации собственных учебных программ для жизни. Однако, не готов дать такой ответ по общему объему учебных программ. Совершенно точно должен быть исключен из обучения второй иностранный язык с одним уроком в неделю, но может эти часы отдать на изучение основного иностранного языка. По моему мнению, в школе должна быть шестидневка (за исключением 1-3 классов). Сегодня, по сравнению с СССР в старших классах добавились новые предметы. Например, информатика. И знания по ней необходимы во всех областях. И видимому поэтому был добавлен 1 год (!!!) обучения в среднем образовании (а может потому что перешли на 5-дневку?). Но непонятно, почему этот год обучения был добавлен не для выпускных классов, а в начальную школу, где учебная программа фактически содержит те же самые предметы. Так же необходимо пересматривать состав учебных программ предметов. Уже в 7 классе (да и раньше) ученики достаточно уверенно работают с офисным пакетом, но почему то, во многих школах эти программы "повторяют" почти в каждом классе. Надеюсь, когда-нибудь соберу эти мысли в отдельную статью.
В данном алгоритме я старался основываться только на исходных данных готового расписания. Соответственно здесь не учтены аудитории не указанные в этих расписаниях (например, которые для 1-4 классов). Идентификация аудитории - по названию. Классификация по размеру - если за все распланированное расписание, уроки там были запланированы только для одной подгруппы - это маленькая аудитория. Если не больше класса или 2 подгрупп - стандартная. Все остальные - большие (от 3 подгрупп или 2 классов вместе). Я понимаю, что есть масса исключений, однако для оперативной общей оценки такой алгоритм подходит. Одно из направлений развития этого проекта - чтобы в личном кабинете, после массовой загрузки основных данных по готовому расписанию, пользователь мог уточнить исключения и произвести переоценку (и в конечном итоге смог произвести перерасчет расписания, для поиска более качественного варианта в условиях разных ограничений).
А, кстати, в статье есть пример из "глубинки"... Где нет фей и единорогов... Зарплаты учителей для автора статьи тоже не секрет и свое отношение к этим зарплатам высказано совершенно определенно. Только вот эта статья не про зарплаты...
Спасибо за статью - плюс в карму. Думаю, что не только для меня интересны переводы с юридического на человеческий. Вопрос: может ли быть зарегистрировано в Реестре ПО, являющееся дополнением к заведомо импортному проприетарному ПО? Мы с коллегами написали ПО которое позволяет анализировать сведения в БД JIRA (как бы плагин). Само ПО написано с использованием средств разрешенных Реестром, однако без БД сформированным JIRA не имеет смысла.
Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"...
Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...
Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам.
При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)
Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.
Было бы интересно увидеть как именно выглядит живая карта ресурсов.
Не совсем понял, что именно надо сделать всем исполнителям и как? Списывать время как удобно исполнителям? Это как? А если им удобно раз в неделю? Или раз в месяц? А как при таком подходе в случае превышения зафиксированной трудоемкости узнать сколько нужно времени на завершение задачи?
Обратная связь: Как количественно оценивать результаты работы отдельных сотрудников на программном проекте? Как и какие именно риски Вы оцениваете в ходе проекта (после инициации) и как их предупреждаете? Нужен ли тайм-трекинг на проекте? Как решаете проблемы неравномерности нагрузки на сотрудников? Вы ведёте учёт потерь на проекте? Если да, то каких именно и как?
Однажды Резерфорд зашел поздно вечером в свою лабораторию и увидел там, несмотря на неурочный час, одного из своих сотрудников.
«Что вы делаете здесь так поздно?» — удивился ученый.
«Работаю», — ответил подававший надежды.
«Что же вы, в таком случае, делали днем?»
«Разумеется, работал».
«А утром? Неужели и утром вы тоже работали?»
«И утром тоже».
«Позвольте, — неподдельно изумился Резерфорд, — а когда же вы думаете?»
Прочитать не смог, но осуждаю... Будь проще... По моему, я когда-то это уже слышал... И не раз... И что грустно, народу продолжают нравится такие выводы... Видимо, если так пойдет дальше, не за горами время, когда статьи будут содержать не больше двух-трех "ку"...
Я таки думаю, что не дешевые программисты, а некомпетентные менеджеры...
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах.
Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
Что касается причин "трисоляриса", то я менее всего склонен рассматривать в качестве причин политику. Как меня учили когда-то, политика - всего лишь надстройка над исторически сложившейся экономической системой... То, что я осознал для себя на текущий момент, так это то, что не стоит бороться с мельницами, надо постараться выйти за рамки, понять истинные цели систем частью которых мы являемся и использовать их энергию в
своихинтересах людей, за которых я несу ответственность. Словить невидимый ветер. Не это ли основное предназначение руководителя?Некоторыми результатами экспериментов над живыми людьми, направленных на повышение эффективности управления IT-проектами, я иногда делюсь в своих статьях на Хабре. Если будет время, поглумитесь над ними как следует... ;)
Куда делись руководители с горящими глазами? Дискуссия скатилась в обсуждение проектных технологий и размера зарплаты PM... На мой взгляд причина совсем в другом... Уже не первый год и не в одной компании наблюдаю систему, которую один мой товарищ назвал "три круга". Первый круг - неприкасаемые - директор, его самые близкие замы и их родственники. В этом круге самая высокая зарплата... Второй круг - руководители отвечающие за результат работы. У этих нормальная зарплата по рынку и именно они руководят непосредственными исполнителями. Эти исполнители составляют третий круг и кадровый резерв для второго.
Кроме ответственности за результат, основная задача второго круга - не допускать возмущенных исполнителей к лицам первого круга... Почему возмущенных? Потому, что зарплата третьего круга минимально возможная. Только чтобы проект не сдох. Иногда правда вынуждены держать экспертов... Но в принципе, все же знакомы с законом Паррето... Когда необходимо обеспечить минимально возможное качество, экспертов много не надо...
Время жизни на первом и третьем круге, как правило значительно превышает время жизни на втором круге. С горящими глазами на втором круге долго не продержишься. По опыту, долго на втором круге держатся персонажи, которые умело превозносят руководство и не менее талантливо перекладывают все проблемы на третий круг. Кроме того,
талантливыйглупый руководитель второго круга может додуматься до того, что он может выполнять обязанности лиц первого круга... Таких вообще убивают сразу, пока маленькие... Благо заменить такого руководителя легко, на эти должности всегда конкурс. Поэтому долго тут держатся не самые умные, а самые преданные. Нет, преданные не проекту. Ну сами знаете кому... ;)Как мне кажется, тут лучше обсудить вопрос: в чем причина того, что во многих организациях сложилась такая система? Или у вас как то по другому?
По моему опыту - конечно должен, но не на проекте которым он руководит.
Не соглашусь.
Не надо всех учителей загонять под одну планку. На мой взгляд подавляющее БОЛЬШИНСТВО учителей, как раз наоборот - горячо переживают за своих учеников. Только вида не подают. Никто не хочет ссорится с любимчиками директора. В результате ложка яда, отравляет всю бочку меда. Только это не деготь. Этот яд не имеет ни запаха, ни вкуса, ни цвета. Здесь представлен инструмент который позволяет визуализировать влияние этого яда. Чтобы им не отравляли наших детей.
КТО и как должен его устранить? На мой взгляд, инициировать очищение отравленного расписания, должны РОДИТЕЛИ - родительский комитет. Если ЛЮБОЙ родитель представит нам заявку на загрузку ВАШЕГО расписания в нашу систему - МЫ его загрузим и опубликуем с пометкой что это НЕОФИЦИАЛЬНАЯ ВЕРСИЯ расписания. Обращаю внимание, что мы заинтересованы в сотрудничестве с заинтересованными школами, чтобы работать с официальными версиями расписаний. После чего можно идти к директору разговаривать. Я предполагаю, что в этом случае найти взаимопонимание будет значительно проще. Только давить не надо. Директора школ тоже бывают разные. И у них, поверьте, проблем в нынешних условиях и так выше крыши... Однако отмечу, что доброе слово, подкрепленное объективным анализом расписания уроков на сайте aimfirst.ru действует гораздо убедительнее чем просто доброе слово...
А ЧТО ДЕЛАТЬ потом?
Про алгоритмы оптимизации, я планирую поговорить как нибудь в другой раз. В данном случае не предлагалось менять алгоритмы составления расписания. Сначала надо выработать объективные методы оценки. Может ничего менять не надо? А если менять, что именно менять? Понятно по Голдрату, что нужно устранять ограничения в системе. Однако, в каждом конкретном случае причины могут быть разными. Их надо выявить, опознать среди этих ограничений главное, снизить его влияние до минимума, после чего переформировать расписание (с использованием все того же алгоритма) и опять оценить его заново, выявить новые ограничения, опознать из них ОДНО главное - устранить и т.д. по циклу пока придем к невозможности устранения ограничений.
Автор статьи категорически против четырехдневной недели в школе. Подробности - в статье и в авторских комментариях.
Спасибо. Я джун в C. Джун - это тоже человек. Несколько моментов узнал новых. + в карму.
Тут надо хорошо подумать. Точно должна быть уменьшена дневная нагрузка чтобы количество уроков не превышало 6. Должен быть обеспечен контроль за нормами времени на выполнение домашних заданий, который не должен превышать 3 академических часов (15 академических часов в неделю). У ребенка должно быть время для реализации собственных учебных программ для жизни. Однако, не готов дать такой ответ по общему объему учебных программ. Совершенно точно должен быть исключен из обучения второй иностранный язык с одним уроком в неделю, но может эти часы отдать на изучение основного иностранного языка. По моему мнению, в школе должна быть шестидневка (за исключением 1-3 классов). Сегодня, по сравнению с СССР в старших классах добавились новые предметы. Например, информатика. И знания по ней необходимы во всех областях. И видимому поэтому был добавлен 1 год (!!!) обучения в среднем образовании (а может потому что перешли на 5-дневку?). Но непонятно, почему этот год обучения был добавлен не для выпускных классов, а в начальную школу, где учебная программа фактически содержит те же самые предметы. Так же необходимо пересматривать состав учебных программ предметов. Уже в 7 классе (да и раньше) ученики достаточно уверенно работают с офисным пакетом, но почему то, во многих школах эти программы "повторяют" почти в каждом классе. Надеюсь, когда-нибудь соберу эти мысли в отдельную статью.
В данном алгоритме я старался основываться только на исходных данных готового расписания. Соответственно здесь не учтены аудитории не указанные в этих расписаниях (например, которые для 1-4 классов). Идентификация аудитории - по названию. Классификация по размеру - если за все распланированное расписание, уроки там были запланированы только для одной подгруппы - это маленькая аудитория. Если не больше класса или 2 подгрупп - стандартная. Все остальные - большие (от 3 подгрупп или 2 классов вместе). Я понимаю, что есть масса исключений, однако для оперативной общей оценки такой алгоритм подходит. Одно из направлений развития этого проекта - чтобы в личном кабинете, после массовой загрузки основных данных по готовому расписанию, пользователь мог уточнить исключения и произвести переоценку (и в конечном итоге смог произвести перерасчет расписания, для поиска более качественного варианта в условиях разных ограничений).
А, кстати, в статье есть пример из "глубинки"... Где нет фей и единорогов... Зарплаты учителей для автора статьи тоже не секрет и свое отношение к этим зарплатам высказано совершенно определенно. Только вот эта статья не про зарплаты...
Спасибо за статью - плюс в карму. Думаю, что не только для меня интересны переводы с юридического на человеческий. Вопрос: может ли быть зарегистрировано в Реестре ПО, являющееся дополнением к заведомо импортному проприетарному ПО? Мы с коллегами написали ПО которое позволяет анализировать сведения в БД JIRA (как бы плагин). Само ПО написано с использованием средств разрешенных Реестром, однако без БД сформированным JIRA не имеет смысла.