Золотой франч. Часть 3

Управление - Бизнес-процессы

36
Движемся к завершению кейса для 1С:Франчайзи, который повышает выработку вдвое.

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

Сегодня – сам процесс работы. Но сначала – о главном принципе.

Главный принцип

Многие задаются вопросом – как такое вообще возможно, что выработка вырастет вдвое? За счет чего? Мы что, код сможем быстрее писать? Или снизим его качество? Тяп-ляп и в продакшн? Многие, конечно, не задаются, а просто отрицают и отвергают. Ведь невозможно, чтобы была где-то проверенная методика двукратного ускорения, а никто о ней не знал?

Проблема, на самом деле, банальная – неправильный вектор внимания. Или, проще говоря, вы не туда смотрите. Сузим тему до программистов, хотя принцип универсален.

Какова, по-вашему, идеальная скорость решения задачи клиента программистом 1С? Речь о задаче на разработку или доработку. Подумайте, пока читаете, ответ будет чуть ниже.

Давайте присмотримся к работе программиста 1С. Как думаете, сколько процентов времени он, собственно, программирует (включая все аспекты – написание кода, создание метаданных, макетов и т.д.)? 100 %? 50 %? 20 %?

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

Разум программиста возмутится – ну как же, причем тут вообще объем кода и скорость печати? Есть задачи, где надо тупо и много писать. А есть такие, где надо много читать, думать, анализировать и пробовать, долго отлаживать.

Ок, зайдем с другой стороны. Весь день программист думал, анализировал, пробовал. В итоге написал 50 строк кода, и задача решена. Хороший, правильный код, все проверено и работает. Потратил 8 часов.

Теперь вопрос: за какое время он решит точно такую же задачу от другого клиента? Если просто возьмет готовое решение, то минут 5, верно? Ну, пока там конфигуратор откроется, пока второй, пока скопирует и т.д. А если заново написать, ручками? Полчаса? По дороге еще и ревью сделает, на автомате, и код улучшит. В 16 раз быстрее.

Ладно, черт с ним, с копированием кода. Другой пример. Вы, вместо того, чтобы дать программисту одну задачу, дали 10-20 – сказали: вот трекер, выбирай любую и делай. Что будет дальше?

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

Иногда такой процесс напоминает разведку боем: программист не только читает заголовок задачи и детальное описание, но и комментарии, а потом – лезет в конфигуратор, чтобы понять контекст. Посмотрит, потыкается – фу, скажет, это задача про спецодежду, там черт ногу сломит, в этой УПП. Не, пусть Колян делает. Минут 15 потеряно. Умножаем на 10-20, сколько получится? До 5 часов?

Это ладно, если программист толковый, и ему достаточно контекста для принятия решения. А он, допустим, большой любитель интернета, и пошел искать готовое решение – на том же Инфостарте, или партнерской конференции, или еще где. Время выбора начинает расти с устрашающей скоростью.

Полдня будет выбирать, полдня будет работать. Потери – 50%, т.е. кому-то достаточно правильно выдавать задачу, чтобы повысить выработку вдвое.

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

Дальше, по разумению главного, программист сел и делает. Пусть не очень эффективно, но делает. А что он делает? Иногда – да, решает задачу. Иногда – сидит и обижается. Или ищет причины не делать задачу. Например, готовит перечень вопросов, «без решения которых начинать бессмысленно». Или в интернет тупит, потому что мир не справедлив.

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

Вот и главный принцип нарисовался: смотри туда, где тупит. Нет особого смысла начинать рост эффективности с процесса написания кода, выбора другой среды разработки (типа EDT), всяких приблуд для ускорения кодирования и т.д. Считайте, что когда программист пишет код – он эффективен. Вот прям когда пальцами на клавиатуре стучит, или мышкой формы рисует и реквизиты добавляет.

Основное время теряется там, где программист тупит, а не там, где он пишет код. Несколько вариантов я рассказал.

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

Возвращаемся к вопросу – каково идеальное время решения задачи клиента программистом 1С? Ответ очевиден – ноль. Ну ладно, совсем ноль не бывает, пусть будет 5 минут. Как достигается такое время? Вы уже понимаете: выдачей готового решения. Пришел клиент, сказал свою задачу, а вы ему сразу – решение, которое у вас уже есть. Сколько взять денег – не знаю, ну не за 5 минут работы специалиста, это точно. Можно спорить с этим утверждением, а можно задуматься. Сколько раз вы решали идентичные задачи? Каков процент задач, которые вы решаете в первый раз, и вообще о подобном не слышали? У меня практика небольшая – всего 13 лет, но даже с такой скромной цифрой я понимаю и вижу, что половину задач я уже решал.

Если вооружиться таким подходом, то потребуется совсем немного – писать абстрактные настраиваемые инструменты (вместо контекстного, сиюминутного говнокода) и где-то их хранить. Первое мы обсуждали, второе имеет массу вариантов решения.

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

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

Общее обсуждение входящих задач

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

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

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

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

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

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

Выбор исполнителя по компетенциям в соответствии со стратегией

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

Например, вы решили, что новички должны решать незнакомые задачи 30 % времени. В системе у вас уже есть отчет, который показывает процентное соотношение – сколько знакомых, сколько незнакомых задач он решал. Смотрите на цифры и решайте, в какой момент выдать новую, незнакомую задачу.

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

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

Однозначных советов по выбору «размера куска» нет, потому что все строго индивидуально. Универсален один принцип: за этим размером нужно следить. Разумеется, если вы хотите эффективность повысить, а не собственную значимость. Такой способ самовыражения, как постановка нерешаемых задач, в среде программистов 1С слишком широко применяется, чтобы не говорить о нем.

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

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

Управление взаимопомощью и ее учет

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

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

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

Собственно, тут больше нечего добавить, все подробно рассказано в прошлой статье.

Управление статусами задач

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

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

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

Во втором окне – задачи, принятые в работу, но не имеющие исполнителя. Опустошается так же, после общего обсуждения. По итогам обсуждения оба списка должны стать пустыми. Допустимое время нахождения задачи в статусах «Не принято в работу» и «Не назначен исполнитель» - не более одного рабочего дня.

Если задача не понятна, и требуется уточнение заказчика – задача, вместе со списком вопросов, переезжает в окно/статус «Требуется уточнение» или «Отправлено на доработку» - не важно, как назвать. Важна детерминированность.

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

Во время обсуждения с программистами смотрим на окно «В работе». Оно у нас ранжированное: все понимают, кто какой задачей занимается. Соответственно, есть время нахождения задачи в статусе «В работе», с привязкой к исполнителю, и это время надо контролировать.

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

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

Продолжение следует. По материалам https://business-programming.ru

36

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. acanta 44 29.05.18 10:49 Сейчас в теме
Есть аудиалы, визуалы и кинестетики. Один наиболее эффективный канал восприятия новой информации, остальные вспомогательные.
Переход от ранее известного к новому проходит одинаково по всем каналам.
"Как вы все прекрасно знаете....., " и далее можно говорить о новых технологиях.
2. FIGOR 29.05.18 11:24 Сейчас в теме
Был у нас такой программист, который писал много кода, после которого потом выявляли кучу ошибок в этой куче кода и переписывали весь код.

Программист и "кодировщик" это, в общем-то, ИМХО, два разных человека.
20. leemuar 29.05.18 19:12 Сейчас в теме
(2) разделение на Программиста (думателя) и Кодировщика (делателя) - это сказки. Это еще и неэффективно: большие затраты и потери при коммуникации. Повышайте компетеции разработчиков, количеством строк кода уже никто производительность не замеряет.
jONES1979; LordKim; +2 Ответить
24. AntonSm 30.05.18 09:11 Сейчас в теме
(20) А как замеряют производительность разработчиков?
С вашей точки зрения, как будет правильно?
25. 1c-intelligence 5583 30.05.18 09:17 Сейчас в теме
28. leemuar 30.05.18 11:30 Сейчас в теме
(24) если кратко - количество завершенной работы за единицу времени. Обычно - количество поинтов закрытых задач за спринт.
Здесь нужно много рассказывать почему так: о том, что работа, выполненная на 99%, никому не нужна и не приносит пользы, о делении крупных задач на мелкие, о бесполезности замеров часов, об оценке в абстрактных поинтах и их дефляции с набором опыта разработчиками и многое другое. В публикациях Ивана это есть.
29. AntonSm 30.05.18 11:40 Сейчас в теме
(28) Ясно. Спасибо.
Значит альтернативы абстрактным поинтам вы тоже не видите, я правильно понял?
32. leemuar 30.05.18 12:36 Сейчас в теме
(29) ничего эффективнее поинтов я не встречал, все остальные методики малоэффективны на мой взгляд. У вас какие-то трудности с поинтами? При их применении часто возникают трудности с пониманием командой и объяснением бизнесу/заказчикам. Но суть очень проста на самом деле
26. Поручик 4147 30.05.18 10:14 Сейчас в теме
(2) У нас такой же был. После него почти год выдавливал ошибки в конфе.
27. leemuar 30.05.18 11:11 Сейчас в теме
(26) к сожалению в области царит привычка валить все на ушедших и "героически" разгребать после них, вместо профилактики во время работы. А у вас уже есть код-ревью?
e-9; Dem1urg; neikist; jaroslav.h; Kaval88; +5 Ответить
30. neikist 30.05.18 12:24 Сейчас в теме
(27) Я до сих пор понять не могу почему стандартные довольно best practice в виде автоматизированного тестирования и код ревью в 1с не применяются.
31. genayo 30.05.18 12:27 Сейчас в теме
(30) Потому, что в 90% случаев и без них хорошо :)) А так, потому, что сама 1С до недавнего времени при разработке своих типовых это не применяла.
33. leemuar 30.05.18 12:43 Сейчас в теме
(30) о, это тема отдельного исследования. Применяются, все больше и больше. Если кратко - область еще растет к этому. Основные проблемы: не умеют считать эффективность в долгосрочной перспективе, не было инструментов, низкие стандарты качества, незнание что можно по другому. В последние годы все меняется в лучшую сторону: и инструменты появляются, и считать эффективность учатся, и стандарты растут, и проповедующих людей все больше.
Waanneek; +1 Ответить
37. neikist 30.05.18 16:40 Сейчас в теме
(33) Как то не очень замечаю честно говоря к сожалению, прекрасный пример (34)
38. acanta 44 30.05.18 18:50 Сейчас в теме
(37) Есть ли жизнь за мкадом(с)
39. leemuar 30.05.18 20:25 Сейчас в теме
(37) это нормально. Легаси системы с огромным накопленным функционалом просто так за полгода не обрастают тестами со 100% покрытием. Смотрите шире, на другие команды и другие конфигурации. Все только начинается
34. acanta 44 30.05.18 13:28 Сейчас в теме
(30) О! Напишите пож-ста, где скачать автоматический тест и код ревью для типовой бухгалтерии. А то мы щаз наконфигурачим, а тестировать некому будет.
36. neikist 30.05.18 16:39 Сейчас в теме
(34) 1) Не все дорабатывают типовые 1сные, но например и во франче со своими конфами этого не наблюдаю.
2) Если мы разрабатываем новую функциональность, то ее тестами и покрываем, а то и вовсе по TDD идем.
3) Скачать код ревью? Вы вообще о чем? Зачем вам вообще скачивать чьи то код-ревью, впервые о таком сценарии слышу?
3. Maxisussr 29.05.18 13:17 Сейчас в теме
(0)
В итоге, пришли к одному - нужно нарабатывать, а затем - максимально эффективно продавать готовое. и строить инструменты, повышающую данную эффективность, остальное - лирика. Верно?
Т.е. такому франчу не выгодно связываться с "уникальными" проектами, в которых есть вроде бы стандартная хорошая оплата, но при этом потом данные компетенции не продать никому? И по сути такая модель франча, делающего сложные уникальные проекты, особо не выгодна?
kalyaka; Dmitri93; +2 Ответить
4. genayo 29.05.18 13:20 Сейчас в теме
(3) А это больше к продажникам вопрос - если уникальный проект продадут клиенту задорого, то затраты на программистов вполне окупятся.
7. kudlach 21 29.05.18 13:55 Сейчас в теме
(4)Уже выполненный задорого проект продать не удастся.
Удастся взять заказ на другой проект и тоже выполнить его качественно и задорого ;)
11. genayo 29.05.18 14:34 Сейчас в теме
(7) Именно. На этом и живут крупные франчи. Хотя автор вроде не про них, а про мелкие/средние региональные.
12. Maxisussr 29.05.18 14:48 Сейчас в теме
(11)
Все же данная схема, на мой взгляд, применима к консультантам.
Т.е. к примеру есть типовой ЗУП. Пилят его редко. Там много однотипных проблем, а также сложных, которые потом иногда повторяются и на которых можно закрыть кучу часов, вот там и вдоволь можно развернуться с такой схемой.
13. Maxisussr 29.05.18 14:50 Сейчас в теме
(4)
проект продадут клиенту задорого, то затраты на программистов вполне

Тут уже, наверное, нужно обладать компетанциями разработчика тиражных решений, чтобы потом продукт поддерживать и получать деньги за поддержку.
Т.е. опять же выходит - или уклон - свои тиражные решения и их продажа-поддержка, или консультационные услуги по типовым конфам. Стабильные сферы, прогнозируемые. И иногда "выстреливают" нестандартные проекты, которые скорее исключение, чем правило.
5. profiprog1c 175 29.05.18 13:30 Сейчас в теме
Ну что сказать, человек явно никогда не организовывал свой бизнес и совсем не понимает что это такое. Это как преподаватели в экономических вузах, они вроде и много книг по бизнесу прочитали и все о бизнесе знают, вот только организовать бизнес сами не могут. Так и здесь, автор пытается получить "теоретическое" увеличение производительности в два раза.
Уважаемый автор, где на практике применялась ваша "чудо схема" "золотой франч" и каковы результаты на практике? А расписывать сферических коней в вакууме все умеют.
LordKim; qwinter; Waanneek; DmitryKSL; inf012; acanta; Kaval88; +7 2 Ответить
17. PrinzOfMunchen 77 29.05.18 16:48 Сейчас в теме
(5) Не знаю, где применял подобный подход автор, но я на практике применяю подобный механизм, и он работает. Не всё прям как в статье, но основные принципы такие же.
Результаты улучшились, не в два раза конечно, но улучшились. И появились другие положительные моменты: для той же выработки, люди уже не работают вечерами/ночами/выходными. Нет паники у людей, всё спокойно, выше лояльность сотрудников к компании, её управляемость намного выше.

Программисты ведь реально теряют много времени на "тупняках": выбрать, какую задачу сделать первой, полазить в интернете, отвлечься на что угодно, отложить разнесение задач на потом и благополучно забыть, что делали. И многое другое.Это всё подробно расписывается в ТОС, CCPM, маркетинговых и других исследованиях. Подходы Agile с этим борются.У того же Максима Дорофеева есть много примеров по time(мыслетопливо)-менеджменту.

Эти принципы не с потолка взяты и реально работают. Чем меньше исполнителю давать обязанностей/возможностей думать над тем, над чем не его работа думать, тем больше времени он потратит на свою работу.
Gulloper; qus-qus; +2 1 Ответить
19. profiprog1c 175 29.05.18 17:03 Сейчас в теме
(17) Что значит вы применяете "подобный механизм"??? Опишите ваш механизм, который вы применяете полностью, а не общие фразы.
21. PrinzOfMunchen 77 30.05.18 02:46 Сейчас в теме
(19)
время теряется там, где программист тупит, а не там, где он пишет код

Этот принцип основной.

1.
Общее обсуждение входящих задач

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

2.
Выбор исполнителя по компетенциям в соответствии со стратегией

Этот процесс не регламентирован на бумаге, в должностных инструкциях, но пока команда программистов человек 10-12, и РП с ними на постоянной связи, он и так знает кто в чём компетентен. Периодически (не реже одного раза в квартал) в компании проходит анкетирование, в том числе и на тему пожеланий в направлениях обучения, так что, кому давать задачи определённой тематики так же РП известно.

3.
Управление взаимопомощью и ее учет

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

4.
Управление статусами задач

У нас в системе пока три основных состояния задач, по сути: задача на распределении, задача на исполнители, задача на проверке руководителем. Если задача небольшая, позвонил клиент, срочно надо сделать что-то, полчаса/час - исполнитель сразу выставляет её на себя и делает. Иначе она падет на этап выбора исполнителя. Такие задачи заносят по звонку, либо они падают от клиентов с внешних task-трекеров.

То, о чём говорилось в начале, что нужно сокращать время,
где программист тупит
Для этого список задач, который видит сотрудник, отображается сейчас в соответствии с приоритетами. Контроль выполнения задач по этим самым приоритетам пока на РП.
Система так же может показывать, какой процент от предварительной оценки прошёл, выполнена ли задача, если есть просрочка, то каков её процент, что бы знать когда РП нужно вмешаться.

Если кратко.

Как только у исполнителя появится возможность начать думать над выбором задачи, он больше времени потратит на этот самый выбор, а не на решение.
Чем чаще у исполнителя будут меняться приоритеты задач, чем чаще у него будет "многозадачность", тем большие беспокойство и усталость он будет испытывать.
LordKim; A_Max; mytg; forseil; &rew; accounting_cons; qus-qus; +7 1 Ответить
41. profiprog1c 175 31.05.18 12:28 Сейчас в теме
(21) Все это детский сад. Вы мне объясните, где у вас производительность в два раза выше, чем была??? Все что вы пишите, просто механизмы обычной работы, и эти механизмы используют все, и ваши механизмы далеко не идеальны. Фраза "время теряется там, где программист тупит, а не там, где он пишет код" - это признаки детского сада в работе. Но вы НЕВНИМАТЕЛЬНО читали статью. Автор заявляет, что использование его системы приведет к увеличению выработки программистом В ДВА РАЗА. Вот это все и критикуют. А вам дам совет - внимательно читайте материал статьи, а потом также внимательно читайте комментарии, чтобы не садится в лужу.
42. genayo 31.05.18 13:10 Сейчас в теме
(41) Интересно, автор имел в виду выработку конкретного программиста, или франча в целом?
43. Kaval88 11 31.05.18 13:22 Сейчас в теме
(42)у меня есть подозрения что выработка статей автором увеличена в 2 раза. Предлагаю автору написать статью как писать статьи.
44. genayo 31.05.18 13:31 Сейчас в теме
(43) Не надо, а то ведь напишет. Я вот в шутку попросил его в стихах написать - таки написал...
45. PrinzOfMunchen 77 31.05.18 18:17 Сейчас в теме
(41) Прошу прощения конечно, но мне непонятна ваша агрессия. Я не автор статьи, с ним не знаком, и уж точно не во всём с ним согласен. О чём и было написано.
Не всё прям как в статье, но основные принципы такие же.


Вы мне объясните, где у вас производительность в два раза выше, чем была???


Где вы увидели такое в моих комментариях? Я лишь написал, что она выше. Перечитайте коммент.

Фраза "время теряется там, где программист тупит, а не там, где он пишет код" - это признаки детского сада в работе.

Что в этом такого "дет. садовского"? Уточню, на всякий случай, что тут акцент нужно сделать на слове "теряется". То есть пропадает зазря. Понятно, что средний программист больше времени кодит и думает над тем, что накодить, чем сидит в вк или кс. Ну в идеале, по крайней мере. Но это полезное время, оно не тратится в никуда, не теряется. Это время в работе сотрудника и желательно увеличить и не отвлекать его от этого лишними делами. Например, выбором задач из списка. Не его это должна быть работа. Не согласны с этим?

Но вы НЕВНИМАТЕЛЬНО читали статью. Автор заявляет, что использование его системы приведет к увеличению выработки программистом В ДВА РАЗА. Вот это все и критикуют.

А я разве защищаю автора и его "громкие" заявления? Нисколько.
Да и в моём комментарии написано
Результаты улучшились, не в два раза конечно, но улучшились.


Мне лишь близки общие принципы из статьи. Вы в своём комментарии написали
А расписывать сферических коней в вакууме все умеют.
Я вам привёл пример с практики, какие подходы применяются и как они помогают. Само собой кратко. Вы ожидали подробный отчёт с графиками и цифрами? Понятно, что большинству это известно и многие это и так делают. Но делают как раз потому, что помогают эти принципы, разве нет?
Ваше негодование в том, что это ВЫ и так делаете? Ну хорошо, а я разве пишу, что мой пример это "нарицательный совет" о том как нужно работать, причём именно для франчи, где уже все бизнес-процессы выстроены, хороший руководитель, который всё знает и т.д.? Вроде бы нет. Это лишь основные принципы, которые мы у себя используем и которые нам помогают на практике.

Опишите ваш механизм, который вы применяете полностью, а не общие фразы.
Кратко описал то, что было связано со статьёй.

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

Я, как и, думаю, многие, не против был бы узнать, чем обусловлена такая критичность. Если вы сумеете всё объяснить, а не просто накидать, как вы говорите
общие фразы
буду только рад изменить своё мировосприятие на более правильное.
Gulloper; Артано; +2 1 Ответить
46. qwinter 510 01.06.18 12:50 Сейчас в теме
(45)
Например, выбором задач из списка. Не его это должна быть работа. Не согласны с этим?
Категорически не согласен. Не интересные, тем более повторяющиеся задачи значительно уменьшают работоспособность программиста, и вводят его в хронический стресс. Тут нужен тонкий баланс между задачами которые принудительно распределяют, и задачами которые программист выбирает сам.
48. PrinzOfMunchen 77 01.06.18 15:50 Сейчас в теме
(46)
Тут нужен тонкий баланс между задачами которые принудительно распределяют, и задачами которые программист выбирает сам.

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

Согласитесь же, если есть 2 задачи, по одной из которых срок "вчера" и без неё работа у клиента встаёт, но она не интересная, и та, которая на развитие, не срочная, но интересная. Мы тут должны давать выбор программисту, какую сделать первой?

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

Мне искренне интересно ваше мнение, должен ли программист знать о всех этих сроках, или вообще сам определять, какие задачи уже пора делать, какие ещё нужно согласовать, по каким ещё ждём оплаты от клиента, и прочие управленческие заморочки?
49. qwinter 510 01.06.18 16:22 Сейчас в теме
(48)
Мне искренне интересно ваше мнение, должен ли программист знать о всех этих сроках, или вообще сам определять, какие задачи уже пора делать, какие ещё нужно согласовать, по каким ещё ждём оплаты от клиента, и прочие управленческие заморочки?
Определять какие задачи нужно делать прям сейчас, а какие завтра должен точно не программист.

Знать об управленческих заморочках программисту однозначно надо, если он хочет дорасти до руководителя проектов)
58. PrinzOfMunchen 77 01.06.18 17:46 Сейчас в теме
(49) Вот и мой коммент о том, что выбор порядка задач - ответственность руководителя, а не программиста.)
Как и то, что бы в составе этого списка задач были те, которые хочется видеть самому программисту)

"если он хочет дорасти до руководителя проектов) ".
Как бы я был счастлив, если бы хоть процентов 30 этого хотели... Если человеку это интересно, с радостью помогаю)

"50-летний программист, всегда будет проигрывать 30-летнему."
Тут, как мне кажется, больше от самого человека зависит. Видел тех, у кого и в 50 глаза горят, готов изучать всё новое, до чего только дотянется. Но гораздо чаще приходилось видеть тех, кто уже и в 30 ничего не хочет.

Мой хороший знакомый пришёл руководителем отдела в одну компанию. Средний возраст программистов - 30 лет. Оклад их около 50к (не Москва, деньги для региона хорошие). Им предложили, сдавайте профессионала по платформе, будет вам + 5к к окладу ежемесячно. И никто даже не пошевелился...
50. qwinter 510 01.06.18 16:26 Сейчас в теме
(48) тут надо понимать такую простую вещь, что век программиста как не крути недолог. 50-летний программист, всегда будет проигрывать 30-летнему. Остаться высококлассным программистом до пенсии не получиться ни у кого.
52. Арчибальд 2705 01.06.18 16:39 Сейчас в теме
(50) Экий бред, однако. Хотя бы один случай, когда максимум успеха у программиста был в 30, а не 50 привести можете? Противоположных есть множество.
53. qwinter 510 01.06.18 16:47 Сейчас в теме
(52) Цукерберг стал одним из лучших программистов на планете в 20. А теперь ваша очередь назвать программиста достигшего максимума в 50.
56. Kaval88 11 01.06.18 17:17 Сейчас в теме
(53)Не лучшим программистом, а программистом который предоставил хорошую идею.
62. qwinter 510 01.06.18 21:43 Сейчас в теме
(56) а что по вашему лучший программист?)) Про идею очень посмешило)) ее до Цукерберга уже десять лет множество людей реализовывали в различном виде.
(56)
59. Арчибальд 2705 01.06.18 19:40 Сейчас в теме
(53) Цукерберг не очень-то и программист. Скорее, идеолог. Но я не настаиваю, пусть программист. А после 20 - тупик?
Мои фамилии: Дейкстра, Вирт, Пентковский.
61. qwinter 510 01.06.18 21:27 Сейчас в теме
(59) все трое свой ключевой вклад сделали с 40 до 45, дальше занимались управленческой деятельностью. Сможешь назвать кого нибудь хотя бы сделавшего вклад пусть с 40 до 50 но в последнее десятилетие?
63. Арчибальд 2705 01.06.18 22:05 Сейчас в теме
(61) Пардон, Пентковский в 46 только эмигрировал. Пентиум его имени появился через 5 лет. Может, Вы имеете в виду "программистов 1С"?
64. qwinter 510 02.06.18 09:05 Сейчас в теме
(63) вы так шутите? Пентиумы появились еще до его прихода работать в интелл. В интелее он участвовал в создании расширения simd для П3. И ничего нового (что до иммиграции им не было реализовано в эльбрусе) там нет.
65. Арчибальд 2705 02.06.18 20:31 Сейчас в теме
(64) Как до прихода они могли получить его имя? Ладно, пусть это неподтвержденная легенда, но уж хронология в этой легенде соблюдена.
Я лично знал Пентковского и вполне себе могу оценить его компетентность. На Эльбрусе он и в самом деле не смог продвинуться. Собственно, потому и эмигрировал.
66. qwinter 510 04.06.18 08:18 Сейчас в теме
(65)
но уж хронология в этой легенде соблюдена.
Нет, разработка пентиума началась в 89, к моменту прихода в Интел Пентковского в 91, макет процессора был полностью готов, и шла отладка. А Пентковский возглавил отдел по разработке SIMD, который был внедрен только в П3.
Я лично знал Пентковского и вполне себе могу оценить его компетентность.
Я и не называл его некомпетентным.Я написал, что он в Пентиуме 3 не реализовал ничего нового, чего бы он не реализовывал до этого.

Как ни крути, но после 45-50 человек продолжает работать практически исключительно на старых знаниях. И если в тех же 80-х или 90-х на старых знаниях можно было работать еще лет 15, то сейчас это время сократилось до 5-8 лет, и продолжает стремительно сокращаться.
67. Арчибальд 2705 04.06.18 18:47 Сейчас в теме
(66) Вот теперь практически согласен. С последним абзацем.
68. Vovan1975 14 04.06.18 19:07 Сейчас в теме
(66) чиста для справки

" Лауреатами Нобелевской премии по физике, медицине и химии 2016 года стали исключительно мужчины. Самому младшему из них - 65 лет, большинство же старше 72."


но вы продолжайте дальше втирать про тупых 40-летних
70. qwinter 510 04.06.18 19:23 Сейчас в теме
(68)
Лауреатами Нобелевской премии по физике, медицине и химии 2016
Иногда стоит читать не только заголовки)) По физике за исследования в 1975-1985 годов, по химии 1983-1999 годов.
71. TODD22 17 04.06.18 19:24 Сейчас в теме
(66)
Как ни крути, но после 45-50 человек продолжает работать практически исключительно на старых знаниях. И если в тех же 80-х или 90-х на старых знаниях можно было работать еще лет 15, то сейчас это время сократилось до 5-8 лет, и продолжает стремительно сокращаться.

Ещё беда в том что количество знаний необходимое для работы стремительно увеличивается. В тех же 80х - 90х объём знаний нужен был меньший для выполнения работы чем сейчас.
Для юристов читал исследование ВУЗ проводил. В общем там чуть ли не в 2 раза увеличилось количество необходимых знаний за 10 лет.
69. TODD22 17 04.06.18 19:22 Сейчас в теме
(65)
Как до прихода они могли получить его имя?


"В октябре 1992 года Intel объявила, что процессоры пятого поколения, ранее носившие кодовое имя P5, будут называться Pentium, а не 586, как предполагали многие. Это было вызвано тем, что многие фирмы, производящие процессоры, активно освоили производство «клонов» (и не только) процессоров 386 и 486. Intel собиралась зарегистрировать в качестве торговой марки название «586», чтобы больше никто не смог заниматься производством процессоров с таким названием, однако оказалось, что зарегистрировать цифры в качестве торговой марки нельзя, поэтому было принято решение назвать новые процессоры «Pentium» (за основу было взято др.-греч. πέντε «пять»), что также указывало на поколение данного процессора. 22 марта 1993 года состоялась презентация нового микропроцессора, через несколько месяцев появились и первые компьютеры на основе Pentium."

И вот такая версия ещё гуглится:

"О происхождении этого имени до сих пор бродят легенды. Согласно официальным источникам, его придумала агенство Lexicon Branding, занимающееся созданием новых брендов. Однако, согласно совершенно неофициальным источникам, имя возникло из фамилии одного из ведущих разработчиков — советского ученого В. М. Пентковского, которого Intel пригласила к себе в 1989 году. Есть и третья версия, согласно которой, обе вышеописанных теории верны и слово «Pentium», предложенное Lexicon Branding, это исключительно удачное сочетание латыни и фамилии."
72. Арчибальд 2705 05.06.18 18:22 Сейчас в теме
(69) О чем я и говорю. Хронология соблюдена. Слово "Пентиум" появилось через год после прихода Пентковского.
55. Kaval88 11 01.06.18 17:14 Сейчас в теме
(50) Согласен срок программиста до 40, дальше отношение будет как к пенсионеру.
47. profiprog1c 175 01.06.18 13:05 Сейчас в теме
(45) Я вам коротко попытаю объяснить, что такое детский сад. Есть ваша фраза: "время теряется там, где программист тупит, а не там, где он пишет код". Мне эта ваша фраза напоминает другу фразу, которую я когда то давно встретил на сайте, где какая-то фирма рекламировала свои услуги по 1С. Они писали: "У нас вы получите в два раза больше качества, по цене, в два раза ниже чем у конкурентов". Я запомнил эту фразу, потому что смеялся наверное минут пять. Так вот, "тупит" программист или не "тупит" - все это субъективные понятия. Если вам программист не нравится, он у вас будет "тупить" всегда, а если нравится - то не будет "тупить" никогда. И еще раз вам объясню: автор статьи "Золотой франч" пытается доказать, что можно взять любой франч и повысить выработку труда программиста в два раза и предлагает какие-то средства. Автора начинают справедливо критиковать в комментариях. Но тут же появляются ребята, как вы, которые пишут: "да мы все это у себя используем и у нас все работает". Теперь вопрос: вы это все используете, выработка у программистов поднялась в два раза или нет?
qwinter; Kaval88; +2 2 Ответить
51. PrinzOfMunchen 77 01.06.18 16:36 Сейчас в теме
(47) Давайте тогда, что бы не было путаницы, объясню, что именно я понимаю под словом "тупит".
Приведу небольшую аналогию. Я беру на работу по сборке автомобилей человека на конвейер. Его задачи брать гайку, брать ключ и прикручивать её куда надо. Моя задача, как руководителя, в данной ситуации, обеспечить что бы (упростим для примера):
а. У него был ключ.
б. У него было куда прикручивать гайку.
в. У него была гайка, когда её будет нужно прикрутить.
г. Что бы он знал, куда её нужно прикрутить.

Если у него чего-то из этого нет - он теряет время зазря - "тупит". Если ему приходится, вместо того, что бы заниматься своей работой, ходить искать гайки, проверять качество гаек, договариваться с поставщиками гаек о сроках и ценах, и тому подобное, то это значит, что я как руководитель ни о чём. И рабочий "тупит" - теряет время там, где не нужно. То же самое, если он вместо выполнения работы сидит в инете и смотрит котиков неприлично долгое время.
И на мой взгляд тут два выхода: либо нам повысить требования к работникам, и вешать на них "поиск гаек", либо найти и поставить грамотного руководителя.

Что бы сразу ответить на слова о том, что человек не может кодить круглые сутки. Так и не надо! Я не заинтересован в этом. Иначе человек будет просто уставший. А это снижение скорости работы, куча ошибок... Оно того не стоит.

"выработка у программистов поднялась в два раза".
Опять вы про эти "два раза". Уже несколько раз обращал ваше внимание, что такого мною написано не было. Я же не пишу, автор молодец, всё у него правильно, делайте так же, даже если вы контора на 50000 сотрудников со 100-летней историей, и будете получать в 5 раз больше.

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

В чём выражается их "работа"?
Программистам стало намного спокойнее. Они пришли работать программистами - решают задачи программистов, а не управленцев. За счёт этого, у них появилось больше времени на непосредственную работу. И если раньше, что бы сделать план нужно было работать по выходным и вечерам, то теперь для этого достаточно работы в офисе с 9.00 до 18.00 с часом на обед. И то, из этих 8 рабочих часов многие могут себе позволить пару часов посидеть поиграть, полазить в инете. И если на нём нет супер срочной задачи - пожалуйста. Сотрудники занимаются любимым делом, лояльны к фирме, и рекомендуют её знакомым. Для меня это положительный показатель.
Выработка тоже выросла. Если говорить по конкретным людям, то у одного человека процентов на 35 в месяц. Но это максимум. В среднем процентов на 10-15. С учётом вышесказанного, как мне кажется, уже неплохо.
Артано; +1 1 Ответить
54. profiprog1c 175 01.06.18 16:51 Сейчас в теме
(51) Из вашего длинного описания, я так понял, что программисты тупят - это когда смотрят котиков в интернете. Кстати, смотреть котиков в интернете очень даже не плохо, чтобы расслабить натруженные мозги. Гугл например для своих сотрудников делает игровые комнаты, в которых сотрудники отдыхают во время рабочего дня. Поэтому я так если честно и не понял, что такое программист "тупит" в ваших понятиях. И еще, не нужно приводить примеры про работников, которые должны крутить гайки в автомобилях, потому что пример очень не удачный. Неудачный, потому что, во-первых, мы говорим конкретно о программистах, а не о работниках, которые крутят гайки. А во вторых, если работник, которого взяли крутить гайки начнет заниматься их покупкой, то это значит такой бестолковый руководитель, а работник тут совсем не причем.
57. PrinzOfMunchen 77 01.06.18 17:35 Сейчас в теме
(54)
я так понял, что программисты тупят - это когда смотрят котиков в интернете.

Нет. Во-первых, "тупят" - когда теряют время делая то, что не нужно. Частный случай - "смотреть котиков" в ущерб работе.

Кстати, смотреть котиков в интернете очень даже не плохо, чтобы расслабить натруженные мозги

Так и с этим я согласен, если перечитаете мой коммент чуть внимательнее - увидите.

Неудачный, потому что, во-первых, мы говорим конкретно о программистах, а не о работниках,

А с точки зрения руководства, есть большая разница?

то это значит такой бестолковый руководитель, а работник тут совсем не причем


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

Фраза "время теряется там, где программист тупит, а не там, где он пишет код" - это признаки детского сада в работе.

Давайте я эту фразу переформулирую в то, что для меня равнозначно:
"Программист теряет своё рабочее время, если ему приходится решать не свои задачи".
В такой формулировке же вы со мной согласны?
60. profiprog1c 175 01.06.18 21:14 Сейчас в теме
(57) "Программист теряет своё рабочее время, если ему приходится решать не свои задачи"
"Уборщица теряет своё рабочее время, если ей приходится решать не свои задачи"
"Менеджер по продажам теряет своё рабочее время, если ему приходится решать не свои задачи"
И так можно продолжать до бесконечности.
Поймите - это и так понятно. Вы ушли в дебри. Повторюсь, суть в самой статье "Золотой франч", которая якобы приведет к увеличению выработки программиста в два раза, а вот - это не реально. А вы пишите: "мы используем у себя такую же систему приблизительно". Вот и меня интересует: использование этой системы привело у вас к увеличению выработки программистов в два раза?
6. Vovan1975 14 29.05.18 13:46 Сейчас в теме
Считайте, что когда программист пишет код – он эффективен. Вот прям когда пальцами на клавиатуре стучит, или мышкой формы рисует и реквизиты добавляет.

вот это ржака.

уменьшить время тупежа, заместив его программированием

дорогому автору надо как нибудь попробовать покодить часов по 10 в день без выходных. Тогда до него дойдет интересный факт - мало кто может без проблем херачить по 10 часов в день.
LordKim; ivanov660; biz-intel; zqzq; CSiER; profiprog1c; cerrenesi; +7 Ответить
9. kudlach 21 29.05.18 13:57 Сейчас в теме
(6) Больше скажу. Больше чем 6 часов ежедневно - через 2 недели мозг кипит.
Даже когда кристально понятно что и для чего писать.
profiprog1c; +1 Ответить
23. Артано 627 30.05.18 07:13 Сейчас в теме
(6) Так и не нужно по 10 часов. Правильная организация труда приводит к тому, что нет нужды в авралах, если они вам не нужны специально.
8. Kaval88 11 29.05.18 13:55 Сейчас в теме
(0)Где практическое применение? где показатели до и после? Для чего все это? Что ты такое? Вообщем, статья вилами по воде.
dg15000; rpgshnik; profiprog1c; +3 Ответить
18. Rustig 994 29.05.18 16:58 Сейчас в теме
(8) "знал бы прикуп - жил бы в сочи"... был бы секрет - все жили бы богато (с удвоенной выработкой)
эта статья прежде всего - диалектика накопленного чужого и своего опыта, при чем нашего же коллеги 1С-ника.
давайте дискутировать и придем к общему знаменателю
10. baton_pk 376 29.05.18 14:02 Сейчас в теме
Пришел клиент, сказал свою задачу, а вы ему сразу – решение, которое у вас уже есть.

только вот беда, клиент приходит не с "задачей", клиент приходит с "проблемой", а то и вовсе с неким "видением проблемы".

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

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

Сколько раз вы решали идентичные задачи?

"идентичные" задачи могут в своём решении различаться на все 100%.

Сколько раз вы решали идентичные задачи?

десятки и сотни раз решались "идентичные задачи":
1. не сходятся остатки
2. НДС поплыл
3. минуса в партиях
4. закрытие месяца валится с нехваткой памяти.
5. ещё куча примеров от каждого из нас.

по пальцам могу пересчитать, сколько раз я мог взять свою готовую разработку и применить на новом месте.
mavom; artempo; Waanneek; docerman; AZel84; dachnik; mickey.1cx; Max27; fancy; acanta; profiprog1c; ABudnikov; Infactum; rusmil; CyberCerber; Dmitri93; +16 Ответить
14. kudlach 21 29.05.18 15:46 Сейчас в теме
"Сколько раз решали идентичные задачи?" - это вИдение заказчика.
А причины одинаковых проблем регулярно разные. Способы решения - тем более.
Чаще всего проблемы в неправильном вводе информации сотрудниками заказчика и корректировка неверного ввода данных часто - ручное исправление.
Но косяк во вводе документа отличается от косяка кадрового учета или косяка во вводе структуры компании или политики учета.
Есть один одинаковый инструмент - волшебный пендель. И то, вопрос с какой силой и в какую сторону прикладывать )))
15. Rustig 994 29.05.18 16:43 Сейчас в теме
(0)
Первое, что надо выяснить – решал ли кто-то подобную задачу. Если решал, то назначить его консультантом, или куратором – не важно, как назвать.

интересный подход
а если я работаю один?
16. Rustig 994 29.05.18 16:47 Сейчас в теме
(0) подобный подход реализован в RMS А.Белова - на инфостарте есть инфа
22. rpgshnik 835 30.05.18 06:07 Сейчас в теме
Где скачать "ГенераторСтатейБелокаменцев" ?
Bassgood; LordKim; mavom; qwinter; ifal; karpik666; Waanneek; Interrupted; docerman; DmitryKSL; serega33; Max27; CyberCerber; herfis; ardn; Kaval88; acanta; spezc; +18 Ответить
35. serega33 30.05.18 13:30 Сейчас в теме
73. 1c-intelligence 5583 06.07.18 09:36 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
Оставьте свое сообщение