Я думаю, у нас немного своеобразное «светлое будущее». «Наши» системы должны учитывать реалии. Да, проектное сообщество уже почти дозрело до освобождения от бумаги. Но только при условии, что все будет записано — кто, что, где написал. И по чьему предложению. И по чьему распоряжению. И кто проверил. И кто за это зуб дал. Ну и еще есть фактор «девочек из того отдела». ЭЦП большинство понимает, как изображение ручной подписи на PDF. Я даже не пытаюсь никому рассказывать про удостоверяющие центры.
А вообще — мне интересно, кто-нибудь уже пытается на основе данных из счетов-фактур и накладных строить экономические модели?
Мы с Вами не сходимся в ключевом вопросе — цель ведения бизнеса. Вы, очевидно, полагаете, что бизнес нужен затем, чтобы получать доход. Но вот куда этот доход Вы потом денете? Ну, съездите один-два раза на Канары, а потом надоест. Построите замок, но вскроется куча нюансов, о которых, не владея замком, Вы пока не задумываетесь. Если жена спит с массажистом — замок уже как-то не фонтан, правда? И т.д… Я знаю кучу примеров, когда отдельные индивидуумы могут уже не вести никакой бизнес. Вообще. Но зачем-то трудятся. Одно знаю точно — не ради прибыли.
Дальше, бизнес — это не оборудование. Основная составляющая любого бизнеса — это люди, организация. Сделали команду — решили половину проблем. Создали определенные традиции в коллективе — решили вторую половину (я упоминал только репрессивный аппарат, но — да, есть и другие варианты, только вот при ориентации «инвестора» на пассивный доход люди ему не поверят). Как производить оценку этого нематериального актива в рублях?
Но все это, конечно, слишком близко к философии. Я не то, чтобы критикую Вашу статью, просто хочется предупредить — многие из Ваших потенциальных клиентов имеют совершенно иной взгляд на озвученную Вами тему. Вы можете считать, что они хотят свободы, а они могут хотеть власти или развития цивилизации (по-простому, сбычи мечт).
Насчет этически неприемлемого выражу личное мнение.
1. Этически неприемлемо — разносить сплетни. Т.е. «у одних знакомых моих знакомых есть проблемы с этим продуктом». А если проблемы были у того, кто о них рассказал — что тут неприемлемого?
2. Этически неприемлемо — давать обещания и не выполнять их.
3. Этически неприемлемы «темные паттерны». https://habrahabr.ru/post/198044/
Ну и…
4. Этически неприемлема перезагрузка сервера с сотнями активных пользователей для правки бага, который мешает нажать кнопку одному человеку. Важную кнопку, например, нужен некий реестр, для Заказчика, через 15 минут! Но — сотни пользователей!
Да, я понимаю, что в дотнете либо есть возможность изолировать плагин доменом и вызвать тем самым геморроидальный синдром при обмене с другими частями бизнес-логики (но зато обеспечить выгрузку и вгрузку «на лету»), либо заставить систему постепенно жрать ресурсы загрузкой новых версий плагина в текущий домен. Но — сотни пользователей! Либо меняйте технологию, либо правильно выбирайте компромисс и предупреждайте клиентов о некоторых нюансах заранее.
5. Неужели ни разу не опробовали систему до того, как выпускать ее на рынок, на более-менее крупном предприятии? Проблемы с производительностью не могли появиться у клиентов, если бы они проявились в достаточно крупном пилотном проекте на предприятии, которое по размерам сопоставимо с предприятиями, которые являются клиентами.
Я согласен, что надо иметь финансовую оценку. Но не стоит забывать о физических объектах, которые подлежат этой финансовой оценке.
На мой взгляд, ошибка большинства «инвесторов» — это надежда на «пассивный доход». Т.е. заплатить денег и забыть, пусть само зарабатывается. Я (лично я) такого не видел ни разу (тему «мойдядяработает замчегототамвлукойле, яснимделюсь» пропускаем). Бросил контроль за «физикой» — все, доходы резко упали, а потом пропали — вот правда жизни. Чтобы иметь минимум личного контроля за физикой — нужен хорошо отлаженный структурированный репрессивный аппарат, штат тетенек и дяденек, которые любят тяф-тяф (мама в детстве нелюбила), а их не любит никто. Сами понимаете, найти таких сложновато, даже у прапорщика дочка есть. Поэтому — сам, только сам. Ну и плюс могучая кучка.
Очень хорошо в контроле помогают разрезы и бюджеты. Выделил бюджет, нормировал соотношения в разрезах — и все, получай сигналы. Главное, чтобы их не было чрезмерно много. Не хватает контроля — добавляй сигналы и детализируй учет.
Я тоже не согласен. Более того, скажу, что за СПО стоят, как правило, очень неслабые усилия, пусть даже поначалу небольшой команды разработчиков. СтОят ли они денег? Бывает, что и стоят — просто рук. проекта считает возможным вкладывать свои кровные. Хочет ли рук.проекта получить выгоду? Безусловно — да. Пусть и не всегда «металлическую», но все равно — хочет.
А тот эффект СПО, что другие разработчики могут воспользоваться чужими наработками я бы назвал, скорее, «побочным эффектом», чем целью или непременным условием, для большинства проектов СПО.
Охотно. Дело в том, что если продуктов/проектов/существенных направлений на проекте больше одного — необходимо осуществлять экономическую оценку успешности каждого из них в отдельности.
Как правило, на проект выделяется определенный бюджет плюс закладывается некий рисковый объем. Доходы, конечно, закладываются (исходя из договора или из опыта), но их учет — отдельно. Расходы выделенного бюджета, коль сильнА в них позиция трудозатрат, легко оценить через ставку каждого участника и долю времени в месяц, потраченную им на тот или другой проект. Ну и еще надо не забыть налоги, соц. платежи, аренду и пр…
В общем, вот так просто. Но — страшно, и потому — непопулярно. Бытует, например, метод «займа» из других проектов. Т.е. вышел бюджет — надо вот на том проекте занять и еще на том. Потому, что никто не хочет проблем и все хотят получку. А что на тех проектах уже бабла нет — это никого не волнует, пока до них дело не дойдет. Я бы еще кое-что рассказал, но, боюсь, это уже тема другой статьи…
Книга — штука хорошая, бесспорно. Но и блоги/статьи на хабре отбрасывать тоже не стоит ;-)
Я думаю, после внедрения в нашу жизнь чисто сетевых понятий, таких как «группы», «форумы», «блоги» кое-что все-таки поменялось. Если раньше, чтобы обсудить тему, нужно было написать книгу и поездить на симпозиумы, то теперь нередко достаточно написать кратенький заголовок и надергать себе контактов в группу. Да, это не исключает «холиваров» и «оффтопиков» (кстати, не исключало и раньше — некоторые книги написаны «в ответ» на другие книги), но все же процесс обсуждения сильно упростился.
Автору. Любая книга, особенно теоретическая — это не истина, изложенная печатно, а повод для обсуждения. В лучшем случае — изложенный опыт и основа для следующего исследования. В этом смысле развитие цивилизации в части появления блогов и статеек на хабре, считаю, идет в правильном направлении.
Я думаю, стоило бы упомянуть, что сама подготовка письма с материалами от нескольких отделов в одной конкретной проектной организации занимает теперь (в том числе и благодаря EASLA) несколько минут (чисто на подготовку к отправке). В противовес «от одного дня», как это было раньше. Экономится время на архивировании, на «расшаривании», на правильном заполнении шапки (база контрагентов — вещь!) и т.д… Это точно актуально для проектных организаций, но, думаю, и для других (например, гос.организации по работе с большим количеством физ.лиц) это тоже может иметь большое значение.
Самое важное, что мы имеем — это то, что, благодаря предусмотренным в EASLA возможностям мы не только быстро подготавливаем письма, но и можем за 0..5 минут подготовить отчет, что и когда отправлено (и что зачастую важнее — не отправлено!), без привлечения к этому исполнителей.
PS Да что там, сам исполнитель может теперь отследить, что он отправил, а что — нет!
Я думаю, интерес к анализу таких систем возникает тогда, когда нужно не просто автоматизировать, а автоматизировать для увеличения эффективности. В нашем предприятии, например, использовалась система «Дело». Да, тоже можно складывать, да, тоже можно указывать «в ответ на...» и т.д… Но. когда вопрос встает о том, чтобы связать «Дело» с другой системой — поневоле начинаешь анализировать возможности «Дела» в этом отношении. Да и вообще возможности «Дела».
Любая система обладает некоторыми возможностями выражения логики. Эта система имеет очень широкие возможности. Например, есть модуль для SQL-сервера, который позволяет делать выборку информации из системы. Возможности такие появились не на пустом месте, а результате многолетнего опыта работы с другими системами. В статье описано, как они использованы, на примере «вх/исх». На самом деле, автоматизировано больше. Что позволяет очень хорошо экономить время. Возможно, Александр опишет и другие решения.
Рискну ответить. Разные продукты по-разному позиционируюся, и этот продукт, в принципе, можно отнести к той же группе, что и SharePoint. С точки зрения реализованных функций — очень похоже.
Не совсем понимаю… Если есть дата, за которую работал уже уволенный сотрудник — почему не выводить эти данные?
Эхехе… Там, поди-ка, и бюджет завязан, да?.. Процент исполнения задач, то да се… Бойтесь принятия решений на этой основе… Впрочем, этот вопрос не к программистам. Мы, знаете ли, реальные данные пособирали тут, правда, не в программерской конторе, а в проектной. Грустно, честно говоря…
Я даже скажу больше — изобретена система таймшитов для более-менее стандартных по составу действий проектов. Например, кирпичи укладывать в стеночку. Во всех мегаруководствах такие примеры как раз и рассматривают.
Ну запланировал манагер 80 часов программера на фичу. Тот пил чай 40 часов. Сделал, с учетом чая, за 120. И? Манагер может доказать, что программер пил чай? Ну накажет программера бездоказательно. А программер пойдет к директору и скажет, что манагер его обидел зазря. На замечание, что вот второй программер сделал похожую фичу за 80 часов, он скажет, что в программировании похожих фич нет, и тут есть свои нюансы. Вот и все. Программеру вернут деньги, а манагеру скажут, чтобы не обижал программеров — ведь без них процесс стоит. Не та система, не для программеров она. Для программеров — деньги за результат. И микроаукцион на «я возьмусь за эту фичу за Х рублей».
PS а вообще, из опыта — любая система, построенная на людях, склонна прийти к наименее подходящему для бизнеса состоянию. Потому что напрягаться хочется меньше, а зарабатывать — больше. Поэтому прежде, чем вводить в систему какие-то факторы, надо подумать — что конкретно это улучшит? И улучшит ли? Вдруг будут неожиданные результаты? Диалектика — это вам не цацки-пецки…
Разрешите в тему пару строк. Сейчас как раз занимаюсь системой учета. Т.с-ть, BI. Только не в ИТ-фирме, а в проектной организации. Хотя, в целом, то же самое. Только девочек 80 процентов %)
У нас есть, фактически, несколько систем, и этот головоног срастается сейчас в одну.
Одна система крайне злая — она следит за тем, кто, сколько в какой программе нажимает кнопок, и ведет учет времени по этим нажатиям. Промежутки больше 1 минуты — не идут в зачет. А т.к. файлы открываются, в основном, из СЭД, то — видно, кто, сколько, по каким проектам отработал. Интеллектуальная часть в зачет, конечно, не идет, это все понимают. «Большой брат» в натуре, так сказать. Только камеры нету — мониторы не те. Ногами не пинайте, я тоже программист, и знаю, что обмануть не вопрос. Но ведь они же не программеры :-)
Зачем это нам?
1) Для определения, сколько времени уходит на работу по тем или иным видам работ. Да, через К, да, с учетом мнения нач. отдела. Но — это уже хотя бы примерная база для планирования и раскидывания с учетом загрузки.
2) Для определения топами, кто работает. И кто над чем работает. Очень хорошие данные, на самом деле. Сразу видно, идет работа по нужному проекту, или нет. И видно, что вот этот хорошо работающий товарищ резюме пишет.
3) Для расстановки всего на места своя внутри отдела. Выдали, в общем-то, нач. отделов. А они дали посмотреть всем. И вот тут — противоречивый результат. С одной стороны — да, все узнали, кто почём. Да, с нач. отдела упала проблема обосновывать снижение премии. Да, «отстающие» стали подтягиваться. Но — стали гнобить (еще больше) тех, кто работает хорошо (а их и мало, и они ботаники, которым с женщинами тяжко). И те, кто работает хорошо — стали искать работу, где им будут платить еще больше. Т.е. в этой части — эффект под вопросом. Большим вопросом.
Для определения эффективности продвижения работ, для планирования у нас есть другая система. MS Project. Сколько и чего я с ним наелся — вы себе не представляете. Сейчас он привязан к СЭД. Это в большинстве случаев закрывает вопрос генераченья 500 задач в одном проекте (а их одновременно 40) вручняка и вопрос установки процентов по задачам в 50% случаев. Клево, поверьте. С другой стороны, он привязан к системе списания денег, которая, в свою очередь, привязана к фонду ЗП по отделу. Тут уже клево не всем.
Вопрос мотивации каждого сотрудника по отдельности решается немного другим методом, тут трудозатраты не нужны. Он сам себя мотивировать будет, если ему определить объем работ и сказать «это стоит столько».
И нету у нас даташитов. И не будет. Ни к чему. Потому что бред. А принимать решения на основе бреда у нас никто не собирается. Потому я тут и работаю.
1) Я не считаю необходимым ставить именно солнечные электростанции для того, чтобы обеспечить глобально весь земной шар энергией. В любом месте земного шара доступна аккумулированная в том или ином виде солнечная энергия. Вопрос лишь в том, каким именно образом ее извлекать с наименьшими потерями в трудозатратах.
2) Биомасса на земле, опять же, выращивается везде. Можете считать ее аккумулятором солнечной энергии. Как выразить, насколько хороший это аккумулятор? Два очень простых показателя — м3/Дж, кг/Дж, Джуоли тут подразумеваются извлекаемые, а не теоретически возможные.
3) Я считаю, что для тропиков — выгодно в тропиках (плюс накинем пару тысяч километров, да), для полюса — на полюсе. Потому что доставка аккумулированной солнечной энергии — это тоже трудозатраты. Но этот ответ касается ТОЛЬКО такого способа, как тот, который описан Вами.
Иллюстрацией моего мнения может послужить такой аккумулятор, как ископаемая нефть. Он достаточно интересный человечеству даже для того, чтобы его доставлять за десять тысяч километров. И доставляют его, замечу, не с экватора.
А вообще — мне интересно, кто-нибудь уже пытается на основе данных из счетов-фактур и накладных строить экономические модели?
Дальше, бизнес — это не оборудование. Основная составляющая любого бизнеса — это люди, организация. Сделали команду — решили половину проблем. Создали определенные традиции в коллективе — решили вторую половину (я упоминал только репрессивный аппарат, но — да, есть и другие варианты, только вот при ориентации «инвестора» на пассивный доход люди ему не поверят). Как производить оценку этого нематериального актива в рублях?
Но все это, конечно, слишком близко к философии. Я не то, чтобы критикую Вашу статью, просто хочется предупредить — многие из Ваших потенциальных клиентов имеют совершенно иной взгляд на озвученную Вами тему. Вы можете считать, что они хотят свободы, а они могут хотеть власти или развития цивилизации (по-простому, сбычи мечт).
1. Этически неприемлемо — разносить сплетни. Т.е. «у одних знакомых моих знакомых есть проблемы с этим продуктом». А если проблемы были у того, кто о них рассказал — что тут неприемлемого?
2. Этически неприемлемо — давать обещания и не выполнять их.
3. Этически неприемлемы «темные паттерны». https://habrahabr.ru/post/198044/
Ну и…
4. Этически неприемлема перезагрузка сервера с сотнями активных пользователей для правки бага, который мешает нажать кнопку одному человеку. Важную кнопку, например, нужен некий реестр, для Заказчика, через 15 минут! Но — сотни пользователей!
Да, я понимаю, что в дотнете либо есть возможность изолировать плагин доменом и вызвать тем самым геморроидальный синдром при обмене с другими частями бизнес-логики (но зато обеспечить выгрузку и вгрузку «на лету»), либо заставить систему постепенно жрать ресурсы загрузкой новых версий плагина в текущий домен. Но — сотни пользователей! Либо меняйте технологию, либо правильно выбирайте компромисс и предупреждайте клиентов о некоторых нюансах заранее.
5. Неужели ни разу не опробовали систему до того, как выпускать ее на рынок, на более-менее крупном предприятии? Проблемы с производительностью не могли появиться у клиентов, если бы они проявились в достаточно крупном пилотном проекте на предприятии, которое по размерам сопоставимо с предприятиями, которые являются клиентами.
На мой взгляд, ошибка большинства «инвесторов» — это надежда на «пассивный доход». Т.е. заплатить денег и забыть, пусть само зарабатывается. Я (лично я) такого не видел ни разу (тему «мойдядяработает замчегототамвлукойле, яснимделюсь» пропускаем). Бросил контроль за «физикой» — все, доходы резко упали, а потом пропали — вот правда жизни. Чтобы иметь минимум личного контроля за физикой — нужен хорошо отлаженный структурированный репрессивный аппарат, штат тетенек и дяденек, которые любят тяф-тяф (мама в детстве нелюбила), а их не любит никто. Сами понимаете, найти таких сложновато, даже у прапорщика дочка есть. Поэтому — сам, только сам. Ну и плюс могучая кучка.
Очень хорошо в контроле помогают разрезы и бюджеты. Выделил бюджет, нормировал соотношения в разрезах — и все, получай сигналы. Главное, чтобы их не было чрезмерно много. Не хватает контроля — добавляй сигналы и детализируй учет.
А тот эффект СПО, что другие разработчики могут воспользоваться чужими наработками я бы назвал, скорее, «побочным эффектом», чем целью или непременным условием, для большинства проектов СПО.
Как правило, на проект выделяется определенный бюджет плюс закладывается некий рисковый объем. Доходы, конечно, закладываются (исходя из договора или из опыта), но их учет — отдельно. Расходы выделенного бюджета, коль сильнА в них позиция трудозатрат, легко оценить через ставку каждого участника и долю времени в месяц, потраченную им на тот или другой проект. Ну и еще надо не забыть налоги, соц. платежи, аренду и пр…
В общем, вот так просто. Но — страшно, и потому — непопулярно. Бытует, например, метод «займа» из других проектов. Т.е. вышел бюджет — надо вот на том проекте занять и еще на том. Потому, что никто не хочет проблем и все хотят получку. А что на тех проектах уже бабла нет — это никого не волнует, пока до них дело не дойдет. Я бы еще кое-что рассказал, но, боюсь, это уже тема другой статьи…
Я думаю, после внедрения в нашу жизнь чисто сетевых понятий, таких как «группы», «форумы», «блоги» кое-что все-таки поменялось. Если раньше, чтобы обсудить тему, нужно было написать книгу и поездить на симпозиумы, то теперь нередко достаточно написать кратенький заголовок и надергать себе контактов в группу. Да, это не исключает «холиваров» и «оффтопиков» (кстати, не исключало и раньше — некоторые книги написаны «в ответ» на другие книги), но все же процесс обсуждения сильно упростился.
Автору. Любая книга, особенно теоретическая — это не истина, изложенная печатно, а повод для обсуждения. В лучшем случае — изложенный опыт и основа для следующего исследования. В этом смысле развитие цивилизации в части появления блогов и статеек на хабре, считаю, идет в правильном направлении.
Самое важное, что мы имеем — это то, что, благодаря предусмотренным в EASLA возможностям мы не только быстро подготавливаем письма, но и можем за 0..5 минут подготовить отчет, что и когда отправлено (и что зачастую важнее — не отправлено!), без привлечения к этому исполнителей.
PS Да что там, сам исполнитель может теперь отследить, что он отправил, а что — нет!
Любая система обладает некоторыми возможностями выражения логики. Эта система имеет очень широкие возможности. Например, есть модуль для SQL-сервера, который позволяет делать выборку информации из системы. Возможности такие появились не на пустом месте, а результате многолетнего опыта работы с другими системами. В статье описано, как они использованы, на примере «вх/исх». На самом деле, автоматизировано больше. Что позволяет очень хорошо экономить время. Возможно, Александр опишет и другие решения.
Эхехе… Там, поди-ка, и бюджет завязан, да?.. Процент исполнения задач, то да се… Бойтесь принятия решений на этой основе… Впрочем, этот вопрос не к программистам. Мы, знаете ли, реальные данные пособирали тут, правда, не в программерской конторе, а в проектной. Грустно, честно говоря…
По технической стороне замечание такое — чтобы не попадали «старые» сотрудники", просто приделайте фильтр по дате.
Более общие вопросы — организация чем занимается? Кто графики составляет, как?
Ну запланировал манагер 80 часов программера на фичу. Тот пил чай 40 часов. Сделал, с учетом чая, за 120. И? Манагер может доказать, что программер пил чай? Ну накажет программера бездоказательно. А программер пойдет к директору и скажет, что манагер его обидел зазря. На замечание, что вот второй программер сделал похожую фичу за 80 часов, он скажет, что в программировании похожих фич нет, и тут есть свои нюансы. Вот и все. Программеру вернут деньги, а манагеру скажут, чтобы не обижал программеров — ведь без них процесс стоит. Не та система, не для программеров она. Для программеров — деньги за результат. И микроаукцион на «я возьмусь за эту фичу за Х рублей».
У нас есть, фактически, несколько систем, и этот головоног срастается сейчас в одну.
Одна система крайне злая — она следит за тем, кто, сколько в какой программе нажимает кнопок, и ведет учет времени по этим нажатиям. Промежутки больше 1 минуты — не идут в зачет. А т.к. файлы открываются, в основном, из СЭД, то — видно, кто, сколько, по каким проектам отработал. Интеллектуальная часть в зачет, конечно, не идет, это все понимают. «Большой брат» в натуре, так сказать. Только камеры нету — мониторы не те. Ногами не пинайте, я тоже программист, и знаю, что обмануть не вопрос. Но ведь они же не программеры :-)
Зачем это нам?
1) Для определения, сколько времени уходит на работу по тем или иным видам работ. Да, через К, да, с учетом мнения нач. отдела. Но — это уже хотя бы примерная база для планирования и раскидывания с учетом загрузки.
2) Для определения топами, кто работает. И кто над чем работает. Очень хорошие данные, на самом деле. Сразу видно, идет работа по нужному проекту, или нет. И видно, что вот этот хорошо работающий товарищ резюме пишет.
3) Для расстановки всего на места своя внутри отдела. Выдали, в общем-то, нач. отделов. А они дали посмотреть всем. И вот тут — противоречивый результат. С одной стороны — да, все узнали, кто почём. Да, с нач. отдела упала проблема обосновывать снижение премии. Да, «отстающие» стали подтягиваться. Но — стали гнобить (еще больше) тех, кто работает хорошо (а их и мало, и они ботаники, которым с женщинами тяжко). И те, кто работает хорошо — стали искать работу, где им будут платить еще больше. Т.е. в этой части — эффект под вопросом. Большим вопросом.
Для определения эффективности продвижения работ, для планирования у нас есть другая система. MS Project. Сколько и чего я с ним наелся — вы себе не представляете. Сейчас он привязан к СЭД. Это в большинстве случаев закрывает вопрос генераченья 500 задач в одном проекте (а их одновременно 40) вручняка и вопрос установки процентов по задачам в 50% случаев. Клево, поверьте. С другой стороны, он привязан к системе списания денег, которая, в свою очередь, привязана к фонду ЗП по отделу. Тут уже клево не всем.
Вопрос мотивации каждого сотрудника по отдельности решается немного другим методом, тут трудозатраты не нужны. Он сам себя мотивировать будет, если ему определить объем работ и сказать «это стоит столько».
И нету у нас даташитов. И не будет. Ни к чему. Потому что бред. А принимать решения на основе бреда у нас никто не собирается. Потому я тут и работаю.
2) Биомасса на земле, опять же, выращивается везде. Можете считать ее аккумулятором солнечной энергии. Как выразить, насколько хороший это аккумулятор? Два очень простых показателя — м3/Дж, кг/Дж, Джуоли тут подразумеваются извлекаемые, а не теоретически возможные.
3) Я считаю, что для тропиков — выгодно в тропиках (плюс накинем пару тысяч километров, да), для полюса — на полюсе. Потому что доставка аккумулированной солнечной энергии — это тоже трудозатраты. Но этот ответ касается ТОЛЬКО такого способа, как тот, который описан Вами.
Иллюстрацией моего мнения может послужить такой аккумулятор, как ископаемая нефть. Он достаточно интересный человечеству даже для того, чтобы его доставлять за десять тысяч километров. И доставляют его, замечу, не с экватора.