Увеличение выработки специалиста 1С, или как повысить его производительность

02.10.20

Саморазвитие

На проектах 1С могут возникать ситуации, когда требуется наладить работу системы за ограниченное время – срочно решить проблемы или запустить критичную функциональность к конкретной дате. Как применять технологии крупных интеграторов и организовать работу команды специалистов по штабной модели на конференции Infostart Event 2019 Inception рассказал генеральный директор ООО «Вертер. Сенсорные технологии» Андрей Акулов.

Сегодня мы с вами поговорим про производительность – я думаю, что это тот показатель, который нам всем надо каким-то образом повышать.

Меня зовут Андрей Акулов, я уже больше 15 лет работаю в полях, внедряю различные системы на платформе 1С. Последние 10 лет работал в качестве системного архитектора – на проектах оборонки, на крупных предприятиях, в интеграторах (Microsoft, IBS, Астерос). За все это время накопилось много интересного. Но сейчас мы с вами поговорим о производительности.

 

 

Классическое определение производительности – это количество в единицу времени. Но, к сожалению, оно к нам не подходит.

Нам необходимо еще учитывать такие три показателя, как:

  •  ресурсы;
  •  объем и сложность задач;
  •  и управление проектом и архитектурой.

Давайте попробуем с вами разобрать каждый из этих критериев и в конце определить, что же реально влияет на производительность, и за счет чего мы можем зарабатывать больше, затрачивая в ходе управления задачами и проектом меньшее количество наших ресурсов.

 

Ресурсы

 

 

Давайте возьмем три критерия, которые определяют наши ресурсы. Это:

  •  стоимость;
  •  проектная роль;
  •  и функции, которые выполняет наш специалист.

Соответственно:

  •  условная стоимость проекта – от 1500 руб/час до 3500 руб/час;
  •  проектная роль – стажер, консультант, программист, архитектор;
  •  функции – от тестирования до определения стратегических целей.

Попробуем определить, что у нас определяет баланс.

 

 

Например, возьмем, стажера – он нам обходится в 1500 рублей в час, может выполнять тестирование и документирование продукта.

Берем такого специалиста? В принципе, да. Немного дороговато, но нормально.

 

 

А если мы ему добавим функций – предложим покодировать и попроектировать?

Эта история уже выглядит сомнительно, и мы точно уже понимаем заранее, что стажер именно в плане функциональности, которую мы ему поручаем, будет использоваться неэффективно.

 

 

Давайте посмотрим другую ситуацию – тот же стажер, но мы его закупаем по 3500. И при этом говорим: «Ты у нас будешь только тестировать и писать документацию». Как вы считаете, адекватная схема? Я думаю, что нет.

 

 

Идем дальше – давайте рассмотрим позицию программиста. Итак, мы закупаем программиста за 1500, говорим, что он программист, который занимается только кодированием. Отличная история. Он программирует и все, на что нам с вами нужно уделить дальнейшее внимание, это – организовать ему именно кодирование. Как он кодирует, с какой скоростью, сколько ему задач даем, и какими задачами он будет управлять.

 

 

А если мы берем программиста, ставим ему закупочную цену 3500 и говорим ему, чтобы он за 3500 не только кодировал, но еще и документацию писал.

Честно говоря, я бы так со своими специалистами поступать не стал, потому что я специалисту за высокую ставку предлагаю выполнять неквалифицированную функциональность (с точки зрения его ставки).

 

 

Другая история – программист ко мне приходит и говорит: «Я стою 3500». И я понимаю, что за 3500 я могу его кинуть на отдельное направление, дать ему самые сложные проблемы, самые сложные задачи, которые вызывают у меня постоянную головную боль. Я ему говорю: «Возьми это направление, определись с концепцией, спроектируй, реши, куда ты будешь двигаться, и реши эту проблему – сам закодируй».

Возникает вопрос – что в этой схеме лишнее (относительно функциональности, которую мы предлагаем за 3500)?

При таком подходе кодирование лишнее. Он все-таки больше занимается концепцией и проектированием, либо собственно кодированием. Кодирование в данном случае немного выползает. Это программист, который уже может выполнять функции архитектора. Но если у вас с какой-то темой очень плохо, тогда – да. Берем, платим, сколько он скажет, и мы точно будем знать, что он эту проблему решит.

 

 

Посмотрим архитектора. Допустим, ставка архитектора, по которой мы его покупаем – 3000 рублей. И при этом он и концепцию разрабатывает, и проектирует, и даже кодирует.

Если он недавно перешел из разряда программистов в архитекторы и стал уметь самостоятельно вести направление и даже целый проект, то кодирование – это прикольно, мне тоже нравится кодировать, я умею и люблю программировать, это доставляет мне огромное удовольствие, но, к сожалению, на проекте это уже начинает выглядеть очень неэффективно.

Да, мы можем сделать какую-то узловую точку и получить удовольствие, но когда я кодирую, лучше, чтобы вокруг меня никого не было. В результате теряется координация работ других специалистов.

 

 

Поэтому если смотрим архитектора, то функцию кодирования нужно куда-то передавать. Именно делегировать.

 

 

Отсюда делаем несколько простых выводов – уровень ставки определяет:

  • баланс роли и функции;
  • требования к тому, как вы будете управлять специалистом – если у него ставка высокая, то вы ему и задачи будете давать наиболее сложные;
  • и требования к самой задаче – какие задачи можно давать специалисту за такую стоимость.

 

Четыре подхода к решению задач

 

 

Теперь определим, какие бывают задачи, и что с ними дальше делать.

 

 

Задача (или решение проблемы) – это процесс. Мы с вами являемся специалистами, организующими производственный процесс по переводу проблемы в решение. Соответственно, этот процесс можно организовать по-разному.

Рассмотрим для примера четыре истории:

  •  специалист работает в штате;
  •  некий проектный офис;
  •  структура интегратора;
  •  и некая штабная структура по решению проблемы.

Итак, красной точкой обозначена проблема.

  • Первая ситуация – программист в штате. У него есть проблема, и программист, работая в штате, успешно с ней справляется. При таком подходе развитие, как правило, не идет. Мы с вами можем только поддерживать на достаточно высоком уровне саму целостность системы. С развитием здесь у нас будет не все хорошо.
  • В проектном офисе у нас появляется позиция архитектора и несколько руководителей проектов или подразделений, которые объединяют в себе ресурсы. При этом несколько проектов выполняется параллельно. В данной картине идет борьба за каждый ресурс – программисты выделены в отдельный отдел разработки, и чтобы получить к ним доступ, нужно:
    • договориться со своим руководителем проекта,
    • договориться с руководителем отдела, где находятся программисты.
    • договориться с отделом, где находятся консультанты
    • попробовать всех этих людей в своем проекте объединить и на этом заработать.
  • Следующий пример – интегратор. Здесь у нас появляется еще несколько уровней. Появляются кураторы, директора проектов, отдельные структурные подразделения, отделы, которые объединяют в себе функциональных специалистов, например, специалисты, методисты, которые занимаются только бухгалтерским/налоговым учетом. Соответственно, чтобы получить оттуда специалиста, вы должны его закупить, поэтому бюджет проекта делится между всеми отделами, где вы берете ресурсы.
  • Последняя структура – т.н. штабная. К ней мы пришли не так давно, буквально в последние два года. В штабной структуре у вас есть одно лицо, которое принимает решения по проекту, и есть ресурсы, которые находятся в его прямом подчинении.

Чем штабная структура отличается от всех остальных? Она заточена под решение задач или проблем, которые однозначно возникнут в известное время.

  • Например, вы заходите на проект сегодня, а через месяц у вас сдача НДС. Система не готова, проблема с разработкой, с методологией, много других проблем. А ситуацию нужно решить ровно через месяц, чтобы компания сдала НДС.
  • Другая ситуация – компания запускает какой-то объект, допустим, космодром, на открытие приедет высокое лицо, и нужно сделать так, чтобы к его приезду все работало.
  • Еще одна ситуация – через неделю (максимум через две) ожидается приход большой воды, которая может залить какой-то важный объект. И за эту неделю нужно сделать все, чтобы эту ситуацию купировать.

В таких ситуациях не работают Agile-методы, не работают каскадные методы. Здесь работает штабная модель, ближайшая аналогия которой – структура МЧС, военные структуры, где как раз разворачивается штаб, разворачиваются ресурсы, и объем закрываемых задач или проблем ограничивается только наличием у вас ресурсов. Поэтому когда вам по телевизору говорят, что под такую-то ситуацию выделено столько-то единиц техники, столько-то людей привлечено, все говорят, какие ресурсы выделены для решения таких задач. Это сделано для того, чтобы гарантировать, что эта задача или проблема будет купирована.

С этого момента мы будем говорить именно о штабной структуре. Программист в штате, проектный офис и интегратор – это все хорошо, но долго и не всегда эффективно.

 

Классификация задач

 

 

Руководители проектов почему-то очень любят произносить тезис «Хаос нельзя автоматизировать». И кичатся этим, говоря заказчикам, что автоматизировать их хаос невозможно. Но это ложный тезис, потому что существует достаточно простая методика по решению проблемы хаоса задач.

Простой пример – вы заходите на предприятие и знаете, что у них проблема с выполнением заявок. Допустим, сейчас на блоке «Техническая поддержка» в трекере висит 1500 задач, и при этом через месяц должен быть сдан НДС, или компания должна открыть филиалы, или перейти с автоматизации каждого филиала по отдельности на централизованную структуру автоматизации. Сроки известны, бюджеты выделены, к этому нужно успеть подготовиться, но при этом задач у вас однозначно больше, чем вы можете сделать (подразумевается, что у вас ограниченное количество ресурсов). Что будем делать?

 

 

Как ориентироваться в этих огромных системах HelpDesk или Excel-табличках, где перечислено несколько тысяч задач в огромном списке?

В данном случае я обращаюсь к специалистам, архитекторам, руководителям проектов – берете все задачи и делите их ровно на три блока (три классификатора):

  •  тип задачи: ошибка, консультация, разработка;
  •  к какому функциональному блоку задача относится: продажи, производство, склад;
  •  какой объект метаданных генерирует эту ошибку.

Вы не должны решать каждую задачу по отдельности – прежде чем решать задачи, вам нужно классифицировать их. Такая классификация на уровне 1500 задач проводится примерно за выходные дни. В пятницу вы садитесь за этот список – у вас еще хаос в голове, за выходные вы проводите классификацию по трем критериям, в понедельник вы уже знаете проблемные точки, куда нужно будет бросить ресурсы.

Вам не нужно кидать ваших разработчиков на решение разноплановых задач – определяете приоритетный функциональный блок:

  • например, если бизнес вашего клиента – это продавать и отгружать, то первое, что нужно сделать – это накинуться на блок «Продажи» и купировать проблему с документом «Заказ клиента»;
  • после этого мы анализируем список задач и понимаем, что у нас есть еще отдельный процесс (например, маркировка обуви), который вообще непонятно, как делать, но он затрагивает всю компанию. Значит, ставим на это направление отдельного человека, и пускай он им аккуратно занимается.

В результате у вас вместо хаоса получается вполне понимаемая система для принятия решений.

 

 

Здесь показан метод классификации. Я не буду подробно на нем останавливаться. Смысл в том, что у вас на входе есть некий список задач:

  • вы эти задачи классифицируете – ошибка/разработка/консультация или проект;
  • внутри каждого блока вы задачи классифицируете уже более детально – и на каждую отдельную составляющую выделяете ресурсы;
  • если ресурсов на это у вас нет, то хотя бы определите, какой объект метаданных генерирует ошибку. Если вы обнаружите, что у вас из месяца в месяц, из недели в неделю возникают одни и те же ошибки, может, стоит посмотреть в исходную ситуацию – что же там такое происходит, что заказ клиента постоянно генерирует нам ошибку.

 

Сравнение методик управления проектом

 

 

Есть несколько методик управления проектом. Выделяют две:

  • каскадная;
  • и различные варианты гибких Agile-методик – Scrum, Kanban и т.д.

Каскадная модель предполагает последовательное выполнение этапов проекта и много документации, которая долго делается, согласовывается и не всегда доходит до реализации. Но при этом все заняты. Вот такая очень затратная, медленная и совсем не гибкая модель.

 

 

Вариант с Agile подразумевает, что мы делим разработку на отдельные периоды (двухнедельные или больше), внутри каждого определяем список задач, и в течение недели проводим анализ, берем задачи в работу и отдаем сделанную функциональность заказчику. Модель не самая плохая, но она тоже не имеет определенных сроков и предполагает, что этот ужас может длиться без конца – таких двухнедельных периодов вы можете нарезать сколько угодно

 

 

Давайте посмотрим, как работает штабная модель. Она работает следующим образом:

  • вы на вход получаете список структурированных проблем и задач;
  • у вас есть срок, причем такой срок, который горит, и который никак нельзя превысить и нарушить;
  • у вас есть рабочая группа с лидером, который внутри рабочей группы определяет, как вы будете решать эти задачи – куда будут кидаться ресурсы;
  • соответственно, у вас на выходе рождается определенное количество релизов.

Мы доходили до того, что когда идет внедрение, релизы могут рождаться каждый час – т.е. информационная система компании-заказчика постоянно находится в режиме изменения. С одной стороны, сотрудники заказчика к этому очень быстро привыкают, потому что понимают, что у них тут же все исправляется, функциональность добавляется. Но это требует от них определенных усилий, поэтому работа в таком форс-мажорном состоянии длительное время чревата увольнением сотрудников у самих заказчиков.

 

Особенности управления проектом при штабной модели

 

 

Давайте попробуем определить, какие требования у нас будут предъявляться к управлению проектом.

Итак, у нас есть ресурсы, у которых есть:

  •  стоимость;
  •  проектная роль;
  •  функциональность.

У нас есть классифицированные по типам задачи, отсортированные по трем критериям:

  •  владелец проблемы;
  •  срочность;
  •  важность

Владелец проблемы стоит на первом месте. Неправильно классифицировать задачи только по важности и срочности. Гораздо важнее то, у кого находятся ваши деньги. Если у вас есть задачи и от финансового директора, и от руководителя отдела склада – тут очевидно, куда следует направить ресурсы. Но если со склада нельзя отгрузить, и клиент из-за этого начинает терять деньги, вам уже нужно будет договариваться о приоритетах с руководством заказчика.

Итак, мы с вами выбрали некую штабную модель управления проектом, и теперь нам нужно определить, как мы всем этим будем управлять:

  • нам важно быстро принимать решения;
  • у нас нет времени на написание ТЗ;
  • при этом нам необходимо иметь всю необходимую информацию, даже если мы постоянно находимся в режиме неопределенности – не знаем, какие задачи прилетят завтра, не знаем, как наши действия повлияют на дальнейший ход событий;
  • для этого важно, чтобы заказчик и исполнитель все время работали вместе – не получится так, что вы получили задачу, ушли, а потом через месяц пришли, внедрили и все круто – вы каждый день в режиме 24/7 находитесь в процессе решения проблем заказчика;
  • естественно, при таком подходе никакой демократии быть не может.

Какие требования мы выделяем к управлению проектом:

  • наличие заказчика с проблемой;
  • наличие командира со стороны исполнителя;
  • организация самого штаба на объекте заказчика или на каждом объекте, который подпадает под ваш периметр автоматизации;
  • и простой инструмент коммуникации для управления самим проектом.

 

Управление задачами при штабной модели

 

 

На слайде показан пример того, как мы проводим первичную стратегическую сессию и определяем объем проекта. Мы собираемся с заказчиком и начинаем рисовать процессы на стене с помощью стикеров.

  • синие стикеры определяют группу процессов;
  • зеленые стикеры определяют функциональность, которая должна выполняться – даже если мы не знаем, как эту функциональность реализовать, но знаем, что там есть или может появиться какая-то проблема, мы это сразу обозначаем.

На стикеры мы вешаем закладки по светофорному принципу:

  • красным мы отмечаем стикеры, соответствующие нерешенным проблемам (в самом начале пути все стикеры помечены красными закладками);
  • когда мы какую-то функциональность уже реализовали, и она у нас находится в режиме тестирования, мы меняем закладку – наклеиваем желтую;
  • и когда проблема уже решена, мы наклеиваем на стикер зеленую закладку.

Эти закладки мы называем индикаторами.

После того как мы определили проблемы, эта картина у нас висит с первого дня и практически до конца проекта. Она очень редко меняется – на ней могут только меняться индикаторы.

При этом не пишется отдельная документация, расписывающая, как мы будем делать то или другое. Предполагается, что мы просто берем очередной проблемный стикер и реализуем соответствующую ему функциональность.

 

Организация штаба

 

 

На слайде показано, как организован наш штаб:

  • заказчик предоставляет нам помещение с необходимым количеством компьютеров / мониторов (или мы сами их привозим – как договоримся);
  • все стены в помещении мы заклеиваем бумажками;
  • и, соответственно, внутри мы проводим некие стратегические сессии, где определяем, какое у нас ближайшее направление развития.

Даже если я, например, нахожусь в Москве, а объект заказчика находится, скажем, в Воронеже, в Калуге или еще где-то. При этом мы настаиваем, чтобы заказчик выделил нам помещение, где никого кроме нас не будет, чтобы мы в любой момент могли туда приехать, и это помещение нас ждало.

Мы выставляем требование – нам нужны вторые мониторы и беспрепятственный доступ на территорию в режиме 24/7. Мы создаем условия для того, чтобы оперативно решать проблемы. Если нам нужно выехать сегодня, у нас с этим проблем никогда не бывает.

Мы уже давно работаем в этом режиме – взяли, накинулись, проблему решили, идем дальше. Находиться в офисе и спокойно пить кофе у нас не получается.

 

Организация коммуникаций

 

 

Теперь – как мы всем этим управляем.

Поскольку большая часть сотрудников у нас работает удаленно, мы в качестве инструмента управления людьми для себя выбрали мессенджер Discord.

Кружки слева – это наши проекты. Для выделенного проекта мы видим группы обсуждений, которые к нему относятся.

Все планирование и подтверждение итогов по проекту у нас проходит в отдельной группе «планерка». На слайде показаны сообщения в этой группе – здесь специалисты пишут план работы на день и в конце дня пишут некий итог. Этого достаточно. Если специалист по итогам дня у меня здесь не отчитался, я ему ставлю двухдневный штраф.

У нас нет бюрократии, нет совещаний, за счет этого мы не тратим время.

Мы для себя выработали определенные правила. В чате одновременно находятся и сотрудники исполнителя, и сотрудники заказчика, в том числе, лица принимающие решения – владельцы, генеральные директора, руководители подразделений. Сотрудники заказчика не вмешиваются в оперативное управление, ничего не пишут в чате – они не могут ставить задачи специалистам, могут просто наблюдать. Это приводит к очень интересным результатам.

Когда программист долгое время не проявляет активности, у всех сразу возникает подозрение – чем он занимается? Либо он пошел по неправильному пути и начинает разрабатывать что-то не то. Либо он ушел, либо он занимается чем-то другим. В определенный момент все начинают привыкать к тому, что чат – это отдельная жизнь. И если в чате долго нет активности, у всех это вызывает огромное подозрение. У нас есть внутреннее правило – каждый специалист должен не чаще чем раз в 15 минут сделать публикацию в чате.

 

 

Я уже говорил, что мы делим чат по проектам и по темам.

На слайде показан пример коммуникации по проекту, когда мы готовим объект заказчика к запуску. Это один день из жизни нашей команды – здесь вы можете посмотреть, как мы проводим коммуникации с командой. Видно, какие проблемы возникают, как мы их решаем.

 

 

Это – живое общение, решение проблем. Причем проблемы могут прилетать абсолютно неожиданные.

 

 

Тем не менее, мы за тот день полностью подготовили объект заказчика к внедрению.

 

 

Здесь мы выкладываем скриншоты, обсуждаем разработку.

 

 

При этом постановка задачи программисту проводится примерно так:

  • у меня в голове есть некая картина, как это будет выглядеть, я примерно понимаю первые шаги, которые нужно сделать разработчику, и формулирую эти шаги в обсуждении;
  • он их делает и выкладывает в обсуждение результат в виде скриншота;
  • мы вместе смотрим, что получилось, и ставим следующую задачу.

 

 

У нас никогда разработчик не работает по некоему заданию – не бывает такого, что дали ему задание, и он ушел с ним работать.

 

 

Если разработчик к нам приходит, мы постоянно видим его результат работы. При этом мы достаточно гибкие. У нас есть свои разработчики и те, кто к нам приходит. Поэтому если хотите поучаствовать в наших проектах, обращайтесь ко мне – мы договоримся.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

вчера в 09:10    160    0    Radio_Analyst    0    

3

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    325    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    334    0    DuyunElena    0    

3

Радио "Аналитик", 13 выпуск 2 сезона. "Путь аналитика" с Анастасией Лощиловой. От финансового директора на заводе до функционального архитектора

Обучение и наставничество Бесплатно (free)

Что отличает аналитика от самурая? Аналитик не прокладывает путь, пока не поставит цель. В серии “Путь аналитика” поговорим, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

20.02.2024    475    0    Radio_Analyst    0    

1

Презентация продукта как искусство

Презентации и публичные выступления Бесплатно (free)

Никакой продажник не продаст ВАШ продукт лучше ВАС. Но презентация продукта – это не только наука, но и искусство. О том, как сделать выступление запоминающимся, насколько важны базовые ораторские навыки, сторителлинг и инструментарий для наглядного погружения в детали, расскажем в статье.

12.02.2024    913    0    comol    4    

17

Личный бренд в IT: а оно вообще надо?

Личная эффективность Бесплатно (free)

Персональный личный бренд повышает вашу стоимость на рынке труда – чем больше потенциальные работодатели знают о ваших достижениях, тем больше они готовы вам платить. Но что делать на старте, когда вы решили прокачать своё имя в отрасли? Какие инструменты и подходы для этого необходимо использовать? О том, как прокачать свой бренд, принося пользу компании, пойдет речь в статье.

01.02.2024    827    0    mitinskiy    2    

7

Зачем программисту книжки читать

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    2772    0    a_a_burlakov    25    

46

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1648    0    KChebykina    0    

31
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. FatPanzer 02.10.20 12:22 Сейчас в теме
(0)
срочно решить проблемы или запустить критичную функциональность к конкретной дате
Тогда нет никаких оснований называть это словом "проект"... Для этого в русском языке есть другое слово из семейства псовых рода лисиц.
o.nikolaev; nomad_irk; +2 Ответить
2. verter.me 918 02.10.20 13:20 Сейчас в теме
(1) Проект - это то, что ограничено во времени, ресурсам и результатам. Спецы нужны когда как раз все плохо, и звереныш уже пришел.
3. FatPanzer 02.10.20 13:25 Сейчас в теме
(2)
Спецы нужны когда как раз все плохо, и звереныш уже пришел.
Ага, значит на проектах спецы не нужны. Нужна серая дешевая рентабельная масса.
Теперь я еще больше понимаю, почему ни разу в жизни не видел ни одного нормально закончившегося проекта от франчей...
lefthander; morin; +2 Ответить
6. verter.me 918 02.10.20 18:13 Сейчас в теме
(3) Я к тому, что ИТ-спецы нужны когда у клиента проблема. Если у него проблем нет - зачем ему ИТ?
10. FatPanzer 02.10.20 19:35 Сейчас в теме
(6) Это в корне не верный подход. Я удивлен, что вы, айтишник, рассматриваете айтишников только как кризисных решал проблем. Я вот думаю - если на складе ничего не воруют, то зачем платить за охранную сигнализацию и за штат сторожей? Да и забор можно снести, чтобы не красить его каждый год...
36. lefthander 16.10.20 10:53 Сейчас в теме
(10)Опять же не отвлекаются сотрудники наблюдающие в системы видеорегистрации ;)
verter.me; +1 Ответить
11. FatPanzer 02.10.20 19:47 Сейчас в теме
(6) Есть еще такая вещь, как работа на опережение проблем. Потому что когда у клиента появляется проблема в ИТ - быстро её уже не решить, он уже как обычно наворотил фундаментальных ошибок, а отчет ему нужен завтра. Именно для этого и нужно ИТ в компании. Как ДПС на дороге - не для растаскивания аварий, а для их предотвращения и создания условий для их отсутствия...
34. lefthander 16.10.20 10:49 Сейчас в теме
(6)У него другая проблема - нет ИТ! Нет? ;)
49. trigor 26 17.10.20 13:14 Сейчас в теме
(6) Проблема решена. Шатер штаба свернули. Проблема не вернется ни в каком качестве?
50. FatPanzer 17.10.20 13:23 Сейчас в теме
(49) Нет, не вернется. Появятся две новые.
51. verter.me 918 20.10.20 12:47 Сейчас в теме
(49) мир так быстро меняется, что никто не знает, что будет дальше. Проблему купировали. Какое-то время ситуация будет стабильна. Но фирма развивается, сотрудники меняются, появляются новые версии 1С. Однозначно можно заверить только в том, что проблемы были, есть и будут.
18. RustIG 1301 04.10.20 17:26 Сейчас в теме
(3) "франч" - это история про всех - многие развиваются по франчайзинговой модели - я не только про программистов 1с.

у франчей 1С есть один неоспоримый плюс - зарабатывать с продаж лицензий и обновлений - за счет этого канала заработка можно оплачивать непредвиденные работы за свой счет - а не за счет заказчика.

плюс 1с-франчайзи - это уже сообщество, которое не только конкурирует, но и помогает друг другу.

в общем, я не понимаю вашей недоброжелательности в отношении франчей
19. FatPanzer 04.10.20 17:30 Сейчас в теме
(18) Они могут быть очень крутыми милашками в своём собственном кругу. Они круто осваивают бюджеты. И они не работают на качество.
А по качеству работ франчей судят обо всех.
lefthander; +1 Ответить
21. RustIG 1301 04.10.20 17:35 Сейчас в теме
(19) просто у вас есть негативный опыт - что крупные франчи продают лицензий, без внедрений - а потом Заказчики ищут новых подрядчиков.... Но я сталкивался с подобным - и что я скажу:
а) это никак не связано со всеми франчами, я например тоже франч
а) это не связано с темой публикации
и
а) это внутренние проблемы Заказчика, у которого рук-во пилит бюджет - пусть между собой сами разберутся
22. FatPanzer 04.10.20 18:04 Сейчас в теме
(21) Да нет же )) Я просто сталкивался как наемом франчей, так и с программистами, вышедшими из под крыла франчей.
Понимаете, там другая идеология - лишь бы работало немного и реализуемо быстро.
Например, программисты одного уважаемого франча потратили неделю на форматирование кода студентов. И пытались нам это продать как работу. Хотя от них явно просили доработать регистр и документы с отчётами, работающими с этим регистром.

Пришедшие из франчей программисты точно так же пытались работать на фиксы у конечного работодателя.

Нет у франчей разработчиков, которых интересует качество своей работы.
Я таких точно не встречал за 20 лет.
trigor; lefthander; morin; o.nikolaev; genayo; ivanov660; +6 Ответить
23. TerveRus 05.10.20 16:46 Сейчас в теме
(22) вот только не надо обобщать по собственному опыту.
Я тоже тигров ни разу на улице не встречал за 30 лет самостоятельных прогулок)
verter.me; +1 Ответить
25. TODD22 18 05.10.20 16:57 Сейчас в теме
(23)
вот только не надо обобщать по собственному опыту.

Но вы же обобщаете...
Я тоже тигров ни разу на улице не встречал за 30 лет самостоятельных прогулок)

Я встречал льва :)
FatPanzer; +1 Ответить
26. genayo 05.10.20 18:32 Сейчас в теме
(23) Ну вот как - есть Бит ERP, и есть остальной Бит. И какое мнение будет у большинства о Бите в целом, как думаете?
27. FatPanzer 05.10.20 22:52 Сейчас в теме
(23) Понимаете в чем дело... Я то обобщаю по состоявшимся случаям, и у меня есть база для такого обобщения. И еще я понимаю, что трудно встретить тигра там, где они не водятся. Даже термин такой есть - репрезентативность.
28. TerveRus 06.10.20 08:49 Сейчас в теме
(27) в каком городе такая репрезентативность?
А может вы специально таких ищете? Ну там идете в самый крупный самый дорогой франч.

Я тут недавно так с Тензором (СБИС) столкнулся, рубят деньги ни за что.
Взяли 8000р за "внедрение" обработки, состоящее из пары нажатий кнопок, которые сделал я сам. И пофиг, что все равно не работает, акт давай подписывай и плати еще)

Но такие крупные компании отдельный разговор, там очень много народа, и никто ни за что не отвечает, и дальше менеджера не пробиться, будь ты хоть 100 раз прав. Для них даже репутация не важна, хоть судись с ними хоть что делай.
30. FatPanzer 06.10.20 09:09 Сейчас в теме
(28) Первый БИТ.
Но такие крупные компании отдельный разговор, там очень много народа, и никто ни за что не отвечает
Так я про это же. Чем крупнее франч, тем больше там работает народа, тем больше там пофигизма, тем большее влияние этот народ оказывает на общий уровень квалифицированности 1Сников на рынке. Вот с этой вот идеологией из мультфильма "Аааа, и так сойдёт!!!". Потому как важнее закрыть/подписать акт, чем сделать качественную работу.
o.nikolaev; +1 Ответить
31. o.nikolaev 211 07.10.20 23:24 Сейчас в теме
(30)
Потому как важнее закрыть/подписать акт, чем сделать качественную работу

Вот это вот надо как-то художественно обработать и извлечь из этой простой и ясной стратегии - Герб, Гимн и Миссию франчей. Могу начать - на гербе должен быть изображен эдакий болт, с двумя гайками - правая немного ниже чем левая.
morin; FatPanzer; +2 Ответить
32. FatPanzer 07.10.20 23:40 Сейчас в теме
40. lefthander 16.10.20 11:10 Сейчас в теме
(22)Программисты вышедшие из франчей тоже самое что и франчи, только в единственном числе.
FatPanzer; +1 Ответить
41. FatPanzer 16.10.20 11:21 Сейчас в теме
(40) Как говорили в древности - в мемориз!
42. nomad_irk 68 16.10.20 11:22 Сейчас в теме
(40)ага, прям заметно "....как их там били" © анекдот
43. FatPanzer 16.10.20 11:26 Сейчас в теме
(42) Каждый захудалый оператор из бухгалтерии для них - ЗАКЗАЗЧИК: "Но ведь она ХОЧЕТ!!!"...
44. nomad_irk 68 16.10.20 11:28 Сейчас в теме
(43)Да ладно бы если дело ограничивалось тем, что каждого считают за ЗАКАЗЧИКА, как они при этом выстраивают работу своих подчиненных.....
45. FatPanzer 16.10.20 11:31 Сейчас в теме
(44) А разве такие дослуживаются до руководства в компаниях? Ё-маё... Не сталкивался, чур меня.
46. nomad_irk 68 16.10.20 11:37 Сейчас в теме
(45)Видимо, да. Лично я попал дважды: первый раз взяли в качестве РП, я попал в подчинение. Второй раз - руководитель отдела программистов 1С, я так же был в подчинении, хорошо, что на испытательном сроке.
47. lefthander 16.10.20 11:54 Сейчас в теме
(46)Очень часто финансовый директор переподчиняет себе программиста из отдела ИТ и в отделе появляется "белая ворона", которая работает только в интересах финдира, а руководитель считает что в ИТ полный штат и задачи пилит на ВСЕХ - помните - "нас трое и юноша, а скажут, скажут что нас было четверо..." (с) ;)
48. FatPanzer 16.10.20 11:54 Сейчас в теме
(46) А, точно! Был один РП, правда я был не в подчинении. Пытался угрозами меня уговорить работать в выходные типа - "а мы по предприятию приказ выпустим о производственной необходимости"... Долго он потом удивлялся: "Как это люди отказываются работать по выходным, да еще и в штате где деньги платят? Вот у нас в Рарусе в выходные работали бесплатно, если у заказчика проблема и аврал, и проект надо закрывать..."
Умел еще бухгалтерии наобещать золотые горы, а потом к нам приходил со словами "Надо вчера". Был неоднократно посылаем. Вылетел с работы быстро.
4. nomad_irk 68 02.10.20 13:30 Сейчас в теме
(2)Ээээ....если зверенышь уже пришёл, то о каком "увеличение выработки специалиста 1С" может идти вообще речь?
Не стреляйте в музыканта, он играет как умеет. Не?
FatPanzer; +1 Ответить
7. verter.me 918 02.10.20 18:17 Сейчас в теме
(4) не. Ключевая идея - высокий темп работ, чтобы его поддерживать, без повышения производительности никак. Например отказаться от всего, что отвлекает: совещания, документация в пользу быстрого выдачи результата клиенту.
TerveRus; +1 Ответить
5. maXon777 128 02.10.20 17:54 Сейчас в теме
"я ему ставлю двухдневный штраф." - можете расшифровать?
Очень интересна тема исполнительской дисциплины - каким образом поддерживаете?
8. verter.me 918 02.10.20 18:25 Сейчас в теме
(5) дело не в штрафе, а в том, чтобы в проектный чат писали сообщения с некоторой регулярностью, минимум раз в 15 минут. Так как в чате одновременно находятся как специалисты клиента так и его руководство, то все видят и получают сообщения о новом посте. Они могут даже не читать, но отсутствие активности в чате тут же влечёт встречный звонок с вопросом "у Вас там все хорошо?".
Поэтому для того, чтобы поддерживать активность в чате - и введено такое правило.
Опять же клиенту приятно видеть, как идёт работа над его проектом так сказать изнутри. Как решаются проблемы, как идет процесс выработки решений и их реализация. Мини-сериал такой получается в текстовом виде

Ни разу не применили, но как пугалка вполне срабатывает.
9. FatPanzer 02.10.20 18:44 Сейчас в теме
(8) Написал ползапроса.
Запрос почти работает.
Переделал запрос под новые параметры.
Подумал и решил, что надо переписать процедуру и вынести её в общий модуль.
Придумал параметры этой процедуры.
Рабочий день закончен.

Так что ли?
lefthander; docerman; TerveRus; +3 Ответить
35. lefthander 16.10.20 10:52 Сейчас в теме
(9)Это еще заказчик по ходу дела не вносил корректив, которые отменяют предыдущие коррективы, уточняют те которые были перед предыдушими и развивает те которые разрабатываются сейчас... как это близко и знакомо...;)
54. verter.me 918 20.10.20 12:56 Сейчас в теме
(35) вносит, как не вносит. ситуация меняется постоянно. поэтому и важно понимать как новые вводные влияют на проект и как распределить текущие ресурсы
52. verter.me 918 20.10.20 12:54 Сейчас в теме
(9) это слишком мелкие вопросы, чтобы их обсуждать в чате. Разработчики люди с опытом - сами разберутся с кодом.
53. FatPanzer 20.10.20 12:55 Сейчас в теме
(52) А что тогда должен разработчик обсуждать в чате каждые 15 минут?
65. verter.me 918 20.10.20 13:18 Сейчас в теме
(53) сделал форму - скрин и в чат. прогнал тест - сообщи о результате в чат. прошел контрольную точки- сообщи в чат. Голова заболела и нужно кофе выпить - пиши в чат и делай паузу.
74. FatPanzer 20.10.20 13:25 Сейчас в теме
(65) А теперь представьте вторую сторону - 20 программистов пишут в чат. И каждый из этих 20 программистов вынужден еще и читать все эти сообщения - а вдруг там начальник или заказчик че-то написал?

И о какой еще производительности мне тут будут утверждать?
78. verter.me 918 20.10.20 13:30 Сейчас в теме
(74) у каждого программиста своя сфера ответственности и соотв. канал в чате. на одном проекте работает в среднем около 1-5 программистов. 20 программистов на одном проекте - это очень боольшой проект. Так что нагрузка по координации лежит на архитекторе. Для каждого отдельного программиста все не так динамично, у него один канал, работает в своем темпе, по мере прохождения контрольных точек делается запись в чате.
Работу других программистов в чате смотреть может, но как правило заглушает канал, чтоб не отвлекал - это правда.
Все не так напряжно как может показаться
12. rusmil 262 03.10.20 09:45 Сейчас в теме
(8) Почему именно "минимум раз в 15 минут", такое переключение не снижает выработку? Поставьте себя на место программиста, например Вы решаете сложную задачу нужно минимум 4 часа чтобы составить и отладить правильный запрос, что Вы будете писать в чат 16 раз каждые 15 минут? Мне кажется чисто психологически это напрягает каждые 15 минут переключаться от решения задачи на что-то еще, потом опять вспоминать, на чем остановился.
lefthander; docerman; Vlad_2008; TerveRus; t278; +5 Ответить
13. FatPanzer 03.10.20 09:50 Сейчас в теме
(12) Это надо же еще придумать, что написать, чтобы не было повоторений, и каждые 15 минут было ощущение прогресса. Полный бред.
docerman; o.nikolaev; Vlad_2008; TerveRus; +4 Ответить
57. verter.me 918 20.10.20 13:03 Сейчас в теме
(13) Уважаемый, Вы допускаете оскорбления франчайзи, то, что Вам не нравится называете бредом, завершенные проекты Вы не видели в своей практике. Так не годится.

Нужно быть лояльнее к обществу. А есть есть своя позиция, то пишем статьи, выступаем на конференциях и рассказываем о профессиональных успехах.
А мы заценим
59. FatPanzer 20.10.20 13:07 Сейчас в теме
(57)
Вы допускаете оскорбления франчайзи
В суд, в порядке ГПК. Если конечно вы найдете такую норму как "оскорбление юридического лица" или "оскорбление экономического термина", и вообще понимаете термин "оскорбление"...
Так не годится.
Это ваши проблемы...
А есть есть своя позиция, то пишем статьи, выступаем на конференциях и рассказываем о профессиональных успехах.
Пишите, рассказывайте, выступайте - это абсолютно ваше право. Как и мое право называть дерьмо говном.
68. verter.me 918 20.10.20 13:21 Сейчас в теме
(59) Хамите, братец. Не ценится тут такое.
72. FatPanzer 20.10.20 13:23 Сейчас в теме
(68) Относиться к разработчикам как к говну - тут еще больше не ценится.
76. verter.me 918 20.10.20 13:26 Сейчас в теме
(72) Друг мой, если программист выдерживает темп и выдает качественный результат, то его чуть не на руках носим. А если кто языком треплет, то в бан однозначно
77. user1464234 20.10.20 13:28 Сейчас в теме
(76) носильщиков -то хватает?
79. verter.me 918 20.10.20 13:34 Сейчас в теме
(75) Мы работаем с 10 до 18. Сверхурочные не приветствуем, как и работу в выходные.
15. kalyaka 1050 03.10.20 14:03 Сейчас в теме
(12) Это показатель активности, который легко измерить.
"Деловая активность как замена продуктивности: в отсутствие четких индикаторов того, что значит быть продуктивным и ценным на своем рабочем месте, многие интеллектуальные работники возвращаются к индикаторам продуктивности времен индустриальной эпохи, а именно пытаются производить большое количество материала максимально наглядным образом."
Кэл Ньюпорт.
lefthander; sulfur17; SpaceWolf; +3 Ответить
16. user1464234 03.10.20 14:14 Сейчас в теме
(15)может они апи с регламентным заданием уже прикрутили? Или метроном /песочные часы у каждого? Один клиент может говорить медленно, другой быстро, интересно, как оператор принимающий заказы по телефону перестраивается? Так и поток у программиста может быть разным. Если задача работодателя в том, чтобы скорость была максимальной, как на Брейн ринге, дальше-дальше, то задачи будут пропускать. Если порядок задач принципиально важен, то и логика и скорость пострадают. Обычно в таких системах требуется весь функционал перестраивать каждый раз полностью и с какого-то момента, сохраняя корректность работы как отдельно до изменения, после него и в сумме за общий период.
Пример, сначала в системе были только накладные с процентом оплаты, затем с какого-то числа добавили кассовый ордер, отчет по взаиморасчетам строится по первичке запросом. Через пару лет добавляем регистр взаиморасчеты и вносим остатки. Требуется общий акт сверки и отчеты по дебиторке за весь период.
Секрет в том, что в состоянии потока программист проходит все стадии переделок в одиночку. И разница только в том, на какой стадии он сочтет возможным что-то показать заказчику/консультанту.
FatPanzer; lefthander; +2 Ответить
58. verter.me 918 20.10.20 13:06 Сейчас в теме
(16) Мы выработали принцип - в конкретный момент времени программист всегда работает над одной задачей. Пока ее не завершит новые в работу не берет. т.е. не создается ситуация, когда начинаем бегать по всем задачам пытаясь их все решить.
17. FatPanzer 03.10.20 14:30 Сейчас в теме
(15)
Это показатель активности, который легко измерить.
Это шашечки.
24. TerveRus 05.10.20 16:47 Сейчас в теме
(12) согласен, какие-то бессмысленные пинги программистов, живые они там еще или нет.
60. verter.me 918 20.10.20 13:07 Сейчас в теме
(24) когда пилот на самолете общается с диспетчером - в этом смысл есть? аналогично и с программистом.
37. lefthander 16.10.20 10:56 Сейчас в теме
(12)Это удлиняет нужные 4 часа на целых 16 часов. А при разработке нового функционала именно так и приходится, или прибегают каждые 15 минут с вопросом ну как? есть что посмотреть...или в чате каком нибудь...а когда все обрубаешь прибегают с вопросом - что случилось, почему не отвечаешь? ;)
39. FatPanzer 16.10.20 11:04 Сейчас в теме
(37) Ну у них тоже работа, и они перед своим начальством тоже отчитываются каждые 15 минут: "Спросил у программиста как успехи. Он ответил, что без изменений. Следующий сеанс связи через 15 минут."
lefthander; +1 Ответить
61. verter.me 918 20.10.20 13:10 Сейчас в теме
(37) как минимум мы страхуемся от того, что через 16 часов программист может принести хрень и нужно все переделывать. Более частый контроль за темпом работ и развитием проекта не даёт уйти в космос.
Мы то с Вами знаем, что дай нам только времени и мы такое придумаем и начнем воплощать в коде...
Вот такой творческий поток и необходимо пресекать.
55. verter.me 918 20.10.20 13:00 Сейчас в теме
(12) если программист уходит в себя на 4 часа, то это точно подозрительно. Сделал функционал, скрин и в чат, обсудили - дальше работаем. Представьте что Вы сидите вместе за круглым столом, кодируете и голосом обсуждаете. В чате тоже самое. Вопрос привычки.
56. FatPanzer 20.10.20 13:01 Сейчас в теме
(55)
Представьте что Вы сидите вместе за круглым столом, кодируете и голосом обсуждаете.
Представил. И тут же уволился нах.
67. verter.me 918 20.10.20 13:19 Сейчас в теме
(56) у нас проще - не смог поддерживать темп - просто из проектного чата выключаем и берем другого. Удобно
user1464234; +1 Ответить
69. FatPanzer 20.10.20 13:22 Сейчас в теме
(67)
просто из проектного чата выключаем и берем другого.
В чат берете другого? То есть можно было сразу туда не ходить?
73. verter.me 918 20.10.20 13:25 Сейчас в теме
(69) можно, че ж нельзя-то. Но за денюжку приходят. Мы по 3500 в час программистам платим. Но и требования выставляем, в т.ч. по ведению активности в чате раз в 15 минут.
80. TODD22 18 20.10.20 13:36 Сейчас в теме
(73)
Мы по 3500 в час программистам платим.

Да ладно? На руки 3.5К рублей?
81. verter.me 918 20.10.20 13:47 Сейчас в теме
(80) на руки. все верно. Ну что, будем писать в проектный чат раз в 15 минут?
82. TODD22 18 20.10.20 14:02 Сейчас в теме
(81)
на руки. все верно.

Наруки это на ИП переводите или налоги сами платите и это ФОТ и сотрудник по ТК РФ устроен?
85. verter.me 918 20.10.20 15:22 Сейчас в теме
(82) 3500 это ставка в час. Если у спеца есть ИП, самозанятые или ООО, то вся сумма уходит туда. Иначе ГПХ, в штат пока не берем.
86. TODD22 18 20.10.20 15:36 Сейчас в теме
(85)И загрузка у него полная ? Обеспечен работой на 100 часов по ставке 3.5К ?
87. nomad_irk 68 20.10.20 15:40 Сейчас в теме
(86)Полная - это в среднем 168 часов.
89. TODD22 18 20.10.20 15:42 Сейчас в теме
(87)Ну это не про франчайзи, закрыть "реальных" 120 часов это уже хорошо. А так конечно можно и по 300 часов в месяц закрывать, если заказчик деньги не считает и щедро платит. Но таких уже давно нет....
90. nomad_irk 68 20.10.20 15:43 Сейчас в теме
(89)ну как бы 3.5к часовая ставка для сотрудника - тоже не совсем про франчайзи :)
Либо чего-то не договаривают.....
83. TODD22 18 20.10.20 14:04 Сейчас в теме
(81)
на руки. все верно.

Честно говоря не очень верю в то что можно закрывать всего по 100 часов в месяц и получать по 350К на руки во франче, даже в Мск. Это довольно много.
88. verter.me 918 20.10.20 15:41 Сейчас в теме
(83) У всех программистов полная загрузка. Наша бизнес-модель предусматривает не продажу часов, а производство своих продуктов (в основном это мобильные приложения на платформе 1С для ТСД, Планшетов, сенсорные информационные киоски). Очень большая доля экспериментальных работ, когда нужно найти решение. Например, на последнем проекте нам необходимо было обеспечить учет 300 тысяч уникальных кодов маркировки в день по 40 фабрикам одежды. С наскоку такие вещи не решаются, требуется провести большое количество тестов и выбрать правильный.

Раньше да, работали в основном на проектах и продавались за часы - сейчас продается наш продукт, к нему идет проект и потом поддержка. Это в свою очередь приводит к тому, что у нас стала появляться своя специализация. Не знаю пока хорошо это или плохо. Как следствие, чтобы взять проект в работу, мы первым делом задаем пару вопросов себе:
- можно ли на проекте продать наши решения в виде лицензий?
- сколько продуктов родится по факту реализации проекта и войдут в наш ассортимент?
ответы на эти вопросы определяют возьмем ли мы в принципе проект в работу. Постоянно в поиске пилотов для новых продуктов, которые сейчас разработке. В основном сейчас идут проекты связанные со складской и производственной логистикой.

Соответственно, подход к организации работ такой-же, необходимо выпустить как можно больше продуктов (сейчас у нас в месяц по одному продукту получается выпускать в среднем), плюс обеспечить его развитие и поддержку. В любом случае, объем работ всегда больше чем у нас есть ресурсов. А значит на первое место выходит организация работы команды и повышение производительности. Чтобы обеспечить качество и темп мы закупаем спецов по высокой стоимости.

немного о наших продуктах есть на сайте: verter.me
чуть больше в группе фейсбук: https://www.facebook.com/verter.markirovka
небольшой кейс о работе нашего продукта: https://zen.yandex.ru/media/id/5f01c16b9b743d704f7e32f1/prodaja-markirovannogo-tovara-cherez-komissionera-5f01c355314c9869ab3e5b77
96. vaskomain 28.10.20 11:03 Сейчас в теме
(88) Вы написали загрузка полная. Скажите вы реально программистам на ИП пересылаете ежемесячно полмиллиона (3500×168)¿ И это окупается¿
84. FatPanzer 20.10.20 14:28 Сейчас в теме
14. partizand 129 03.10.20 10:08 Сейчас в теме
(8) программисту лучше оставаться в состоянии потока. Тогда его производительность будет значительно лучше, на мой взгляд. Для этого чат лучше наоборот отключать.
И программирование кусочками может в итоге приводить к частому переписыванию всего ранее написанного. Хотя возможно это оправданная тактика.
lefthander; kalyaka; +2 Ответить
38. lefthander 16.10.20 11:00 Сейчас в теме
(14)При написании нового функционала переписывание неизбежно, так как в процессе написания кода приходят новые мысли и уже решенные вопросы могут потребовать переделки. И в этот момент лучше не отвлекаться, но не все это понимают и не все хотят с этим соглашаться. Это как по Райкину - сидит изобретатель, что то изобретает, а что он там изобретет никто не знает, так может дать в руки молоток пусть гвозди пока забивает... ;)
FatPanzer; +1 Ответить
62. verter.me 918 20.10.20 13:14 Сейчас в теме
(38) Вот именно мысли и могут увести не туда. В результате будет затрачено время, и родится не нужный функционал. Более частый контроль позволяет не сбится с плана и оперативно реагировать на изменения ситуации, а именно это нам и нужно. Высокий темп, высокая неопределенность и ограниченность в ресурсах.
33. docerman 70 16.10.20 10:33 Сейчас в теме
(8)
минимум раз в 15 минут

- самодурство
63. verter.me 918 20.10.20 13:15 Сейчас в теме
(33) А если нет? если благодаря ему Вы сможете выдавать не 1 функция в 4 часа, а 3?
66. user1464234 20.10.20 13:18 Сейчас в теме
(63) поставьте себе будильник на каждые 15 минут и наблюдайте за фазами сна:)
71. verter.me 918 20.10.20 13:23 Сейчас в теме
(66) Ну да, программист даже когда спит - работает.
75. user1464234 20.10.20 13:25 Сейчас в теме
(71) Я так понимаю, что когда программист не спит у него высокая исполнительная дисциплина. А тестирование все равно автоматизированное.
92. docerman 70 20.10.20 18:43 Сейчас в теме
(63) А если не делая этого, работая без самодурства со стороны руководителя и в спокойной обстановке, Вы, как разработчик, можете зарабатывать столько-же и больше?
20. RustIG 1301 04.10.20 17:31 Сейчас в теме
(0) я всегда разделял на такие этапы:
1) эскпресс-обследование,
2) внедрение,
3) сопровождение (после внедрения)

очень понравилась ваша идея и аналогия со штабным управлением, применяемая в МЧС!
64. verter.me 918 20.10.20 13:17 Сейчас в теме
(20) трудно возразить. Если брать крупно, то этапы именно такие. внутри этапов неопределенность большая
29. TerveRus 06.10.20 08:51 Сейчас в теме
О как, я оказывается уже пару лет штаб основал и командую им, и парой солдат)
Ну да, в условиях постоянного аврала и срочных неотложных мелких доработок, кроме как военным штабом это трудно назвать) Постоянно сражаешься с потоком входящих задач и хотелок)
verter.me; +1 Ответить
70. user1464234 20.10.20 13:22 Сейчас в теме
Насчет поддержания темпа и взаимозаменяемости это очень правильный подход.
verter.me; +1 Ответить
93. user1464234 20.10.20 18:50 Сейчас в теме
Вообще для солидного франчайзи подход интересный. Есть у франча в данный момент собственная разработка, нет у франча собственной разработки - это непринципиально. Франчайзинг всегда продает лицензию на свою разработку, сохраняя за собой право как дорабатывать так и предлагать другим клиентам. И никаких проектных ТЗ от клиента, как и оценки работ не требуется.
94. vaskomain 28.10.20 06:41 Сейчас в теме
Так жалко что вы с названием статьи обманули 😶 про личную производительность совершенно ничего. Ваша статья о том, как максимально быстро решить ключевую проблему клиента. Это о результативности, чем о производительности.

Производительность - когда тот же самый объем работ делается за меньший срок или меньшими силами.

Результативность - это как за выделенный срок сделать больше дел, приводящих к нужному результату.
95. vaskomain 28.10.20 07:08 Сейчас в теме
(94) хотя нет, прошу прощения. Один инструмент повышения личной производительности вы указали. Это 15-минутная синхронизация. Понятно как работает инструмент - если за 15 минут программист ушёл не в ту сторону, то вы его быстро вернёте на путь истинный. Те, у кого программист уходит на час или несколько часов - могут потерять больше времени программиста, если он будет делать не то, поэтому там и нужна чёткая постановка задачи.

Но честно говоря мне эти 15 минут сразу что-то напомнили. Это ведь парное программирование! Внедрите парное программирование и эффект от быстрой синхронизации у вас ещё усилится - ведь при таком подходе вы будете терять не более 1 минуты а то и меньше! Вы анализировали сколько у вас потерянных 15-минутных интервалов когда программист делал что-то не то. А у парного программирования помимо эффективности ещё прямо куча плюшек. Это и оперативность тестирования и соблюдение архитектуры и стандартов кодирования, в общем все в том числе что ведёт к снижению техдолга. Подумайте. У вас до этого остался небольшой шаг, в основном в голове
98. verter.me 918 02.11.20 12:23 Сейчас в теме
(95) Верное замечание. По сути с помощью чата происходит т.н. парное программирование - один из элементов экстремального программирования. Скажу больше, программист работает только в паре с архитектором, не с аналитиком. У одного идеи и видение, плюс координация всех работ, у другого реализация. Скорость выдачи результата возрастает в разы. Плюс то, что команда уже слаженная - это также сильно экономит время.
99. vaskomain 02.11.20 14:35 Сейчас в теме
(98)
По сути с помощью чата происходит т.н. парное программирование


Это очень странно.
Па́рное программи́рование — техника программирования, при которой исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. Один программист («ведущий») управляет компьютером и, в основном, думает над кодированием в деталях. Другой программист («штурман»[1]) сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они меняются ролями, обычно, каждые полчаса.

Здесь очень важный аспект - за одним рабочим местом. У вас этот принцип нарушается, без него это уже не парное программирование
100. verter.me 918 02.11.20 18:49 Сейчас в теме
(99) думаю, у нас не настолько все жестко. Зачем необходимо именно одно рабочее место, когда все работают удаленно? Зачем меняться, когда роли определены, ну и так далее. Это все условности. Важно тут другое, есть архитектор, который не кодирует, а именно координирует работу программистов и находится с ними в прямой и постоянной связи. Каждый программист развивает свой функционал и постоянно общается с архитектором.
Принципиальный момент - архитектор не кодирует!!!
Между ними нет пользователей, аналитиков, консультантов, документов, совещаний, планерок и еще кучи всего, что есть у других и что влияет на время реализации от идеи до готового функционала. Мы это все убрали и заменили чатом, плюс максимально приблизили программистов к архитектору. Все просто.
Оставьте свое сообщение