Принципы профессионализма через истории. История первая

07.08.17

Саморазвитие - Истории из профессии

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

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

Помниться лет 9 назад один клиент спросил меня: «Андрей, когда нам ожидать завершения задачи?».

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

Как вам кажется, дал ли я ответ клиенту? Думаю, нет. Что подумал клиент? Он подумал, что я не хочу отвечать на вопрос и поэтому вместо срока даю ворох оправданий.

Что он ждал? Он ждал ответа на вопрос «Когда?». Ответом на этот вопрос могут быть ответы в виде времени или даты. Или в крайнем случае ответ о том, что дату сейчас определить невозможно и назвать срок, через который это будет возможно. И только после этого уже можно давать пояснения. Человек сначала всегда ждет ответа на свой вопрос. Он усиленно пытается его найти в ваших словах, а все остальное воспринимает как непонятный фон.

Клиент оказался очень терпеливым и корректным, и он просто сказал: «Андрей, я ничего не понял. Есть какие-то сложности и вы не можете назвать срок?».

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

Клиент ждал ответа. Молчание уже не прилично затянулось. Я подавил в себе очередную порцию оправданий и сказал правду:

«Могу, но мне кажется он вам не понравиться, поэтому из меня сначала полезли какие-то пояснения причин. Я закончу задачу в пятницу к обеду, а не сегодня, как говорил ранее.»

Очень захотелось извиниться, я подвел клиента. И хотелось показать, что я сейчас ускорился по максимуму и еще быстрее я не могу делать физически.

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

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

«А вы уверенны в текущем сроке?»

Уверен ли я? Сначала я разозлился. Что за сомнения в моем умении оценивать? Но потом мне стало смешно. Это адекватный вопрос. Во-первый один раз я уже ошибся. Во-вторых, я помнил, были случаи, когда я не хотел огорчать клиента и «приукрашивал» срок. Видимо клиент тоже знал о такой особенности людей.

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

Я был действительно уверен. Не люблю ошибаться дважды. Лучше перепроверить все до конца.

«Ок. Жаль, что мы сегодня не получим результат. Но я рад, что дальше в сроках можно будет не сомневаться. Ждем тогда задачу в пятницу к обеду. Только прошу дальше предупреждать меня заранее, а то мы тоже планируем свою работу от ожидаемых от вас результатов».

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

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

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

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

1. Сначала отвечай на конкретный вопрос, а потом уже давай объяснения. Иногда можно даже не давать объяснений, если их никто не ждет в этом разговоре.
2. Если ты ошибся в чем-то, то прежде чем давать обещание перепроверь уверен ли ты, что больше ни в чем не ошибаешься. Второй раз подводить совсем не весело.
3. Постоянно контролируй ожидания клиента. Если есть даже небольшой риск, что ты не сможешь выполнить свое обещание, то надо начинать решать эту проблему сразу. Если после начала решения проблемы уверенности в сроке не появилось, то надо сказать об этом максимально заранее всем заинтересованным лицам.
4. Если ошибся, то извинись, исправь и скажи почему такого больше не будет.

Автор статьи: Андрей Макаров, компания Neti

истории доверие профессионализм

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Истории из профессии Россия Бесплатно (free)

Описываю кейс оптово-розничной компании, где хаос в учёте собственник объяснял не ошибками ведения учёта и интеграции с бухгалтерией, а "высшими процессами" - обрядами в горах Перу.

28.07.2026    561    0    Ferra_Shap    13    

1

Истории из профессии Россия Бесплатно (free)

В данной публикации я расскажу, как я, будучи бухгалтером, пришла в сферу 1С и стала Аналитиком 1С.

21.07.2026    603    0    cheplinok    5    

4

Истории из профессии Бесплатно (free)

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

22.06.2026    625    0    apatyukov    0    

3

Компетенции и навыки Истории из профессии Бесплатно (free)

Чем консультант по постановке управленческого учета отличается от консультанта 1С? Один работает с инструментом. Другой — с учетной функцией бизнеса: людьми, процессами, правилами, данными и ответственностью.

19.06.2026    755    0    apatyukov    3    

2

Истории из профессии Бесплатно (free)

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

16.06.2026    1073    0    apatyukov    16    

12

Истории из профессии Россия Бесплатно (free)

Можно ли после 30 лет, без технического образования, с юридическим прошлым и стабильной службой перейти в IT и стать 1С-разработчиком? А если до льготной пенсии осталось всего три года, вокруг отговаривают, рабочего графика как такового нет, а учиться приходится в 5 утра, по вечерам, в выходные и редкие минуты между делами? Это личная история перехода из правоохранительных органов в 1С: без сказки про легкий вход, но с честным разбором сомнений, подготовки, отказов, первой работы и навыков, которые неожиданно пригодились в новой профессии.

15.06.2026    977    0    NikolayMaerov    22    

6

Истории из профессии Россия Бесплатно (free)

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

09.06.2026    1070    0    apatyukov    25    

11

Коммуникации Истории из профессии Бесплатно (free)

«Почему он, а не я?» обычно звучит как смешная фраза про обиду и сравнение. Но в рабочей команде она становится совсем не смешной, когда человек случайно узнаёт, что коллега на той же роли получает больше. С этого момента одна цифра запускает спираль: сначала недоверие, потом молчание, потом апатия, падение качества и тихий уход.

09.06.2026    1343    0    IgorVasilyev    31    

14
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Сурикат 410 07.08.17 16:52 Сейчас в теме
Спасибо за труд =)
На инфостарте не хватало таких вот рассказов =)

Надеюсь будут еще =)
Andreeei; SP2000; +2 – Ответить
2. Neti 2647 07.08.17 17:05 Сейчас в теме
Будут. Спасибо вам :)
Kinestetik; SP2000; +2 – Ответить
3. troyansky_konb 07.08.17 17:05 Сейчас в теме
4. Pavel_03 07.08.17 21:31 Сейчас в теме
Андрей, хорошая статья) и в целом интересная методика обучения на "историях"
Kinestetik; Alex Gor; SP2000; +3 – Ответить
5. boln 1044 07.08.17 21:59 Сейчас в теме
(0)
Помниться лет 9 назад один клиент спросил меня: «Андрей, когда нам ожидать завершения задачи?».

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

Как вам кажется, дал ли я ответ клиенту? Думаю, нет. Что подумал клиент? Он подумал, что я не хочу отвечать на вопрос и поэтому вместо срока даю ворох оправданий.

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

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

Впоследствии приходилось объяснять эту простую истину много раз, даже старшим и более опытным коллегам.
Kinestetik; semp89; TreeDogNight; Nelli_A86; Anchoret; 2PRV; SP2000; Neti; +8 – Ответить
6. IvanovAV 172 08.08.17 01:20 Сейчас в теме
Был в похожей ситуации, тоже начальник всегда строго требовал срок, и срок я должен был назвать сам. Но я всегда ставил встречное условие, вы меня освобождаете от текучки и техподдержки, я расставляю приоритеты, что эта задача приоритетная, все остальное на второй план, тогда будет готово в такой-то день к стольки часам. Пару раз залетал, приходилось жить на работе и спать по 4 часа в сутки, но с опытом приходит, что предполагаемый срок нужно умножать на два, и нужно не стесняться торговаться во встречных плюшках со стороны руководства. Например бесплатную пиццу к обеду на всю команду, или второй монитор, новую клавиатуру с мышкой и т.д.
Наша работа - это шаг в неизведанное, творчество, все проекты и задачи сугубо индивидуальные. Точно определить срок можно только тогда когда ты эту работу уже делал, и знаешь как ее делать, но в моей работе это единичный случай.
На одной работе нас отлично и почти бесплатно кормили в обед, это было супер, пообедал за 20 минут, и можно еще 40 минут погулять на улице, посмотреть по сторонам, отдохнуть от монитора - эта передышка увеличивала личную производительность.
Rega; begemot; Kinestetik; semp89; Romakon92; OMT; YanTsys; TreeDogNight; N2; Nelli_A86; 1vasia1; Anchoret; AlexeyT1978; cmd_vasec; SP2000; sasha777666; CyberCerber; Сурикат; +18 – Ответить
7. a_a_burlakov 293 08.08.17 08:23 Сейчас в теме
В тему: об этом же кратко, но ёмко пишет Роберт Мартин в своей книге "Идеальный программист".

Читать главы:
- Как сказать "Нет"
- Как сказать "Да"
- Под давлением
Rega; Kinestetik; TreeDogNight; Sure; Gorus; zqzq; SP2000; unichkin; Neti; +9 – Ответить
9. Octopus 351 08.08.17 09:41 Сейчас в теме
(7) Ну не то чтобы емко, он тоже мастер байки из жизни потравить ))))
8. o.nikolaev 219 08.08.17 09:13 Сейчас в теме
Симпатичная статья. Но: "максимально заранее" - "как можно раньше".
65. MuxaH 11.08.17 05:35 Сейчас в теме
(8) Тогда ещё надо проверить "ться" и "тся" и использование "нн" :)
10. JohnGalt 58 08.08.17 10:06 Сейчас в теме
Вообще это очень сложный вопрос о том, что нужно говорить клиенту. Много нужно понимать и уметь объяснить. И еще нужно понимать клиента и возможные варианты его поведения. Одному объяснения действительно лишние, он хочет результат. Другой - наоборот, с удовольствием выслушает, в чем проблема и попытается для себя понять и сделать свою оценку.
TreeDogNight; N2; Neti; +3 – Ответить
11. Irwin 577 08.08.17 11:30 Сейчас в теме
Напомнило одного руководителя отдела. Любил я его на эту тему подначивать. Почему-то он не мог на многие вопросы отвечать просто "Да" или "Нет", а я ему специально задавал вопросы вида "Обработка должна работать в фоне? Да или Нет?". А в ответ слышал что угодно, но только не "Да"/"Нет". То ли был неуверен в себе, то ли не мог принимать решения - не знаю. Но факт, что я этих слов от него практически не слышал.
TreeDogNight; boln; Neti; +3 – Ответить
16. Bassgood 1509 08.08.17 16:39 Сейчас в теме
(11) Возможно он хотел бОльшей самостоятельности в принятии решений от своих подчиненных и меньше забивать себе голову решением технических вопросов? Я тоже не всегда отвечаю как лучше реализовать ту или иную задачу, ожидая что об этом прежде всего подумает сам спрашивающий и предложит свои возможные варианты, но это конечно все индивидуально и зависит от ситуации.
17. Irwin 577 08.08.17 17:01 Сейчас в теме
(16) К сожалению, с ним было именно то, что он не мог ответить Да или Нет. Даже на уже принятые и озвученные им решения.
18. boln 1044 08.08.17 17:07 Сейчас в теме
(17) Отвратительный тип руководителя. Может подставить, свалив на исполнителя всю ответственность за решения, которые должен был принимать он сам.
19. Irwin 577 08.08.17 17:19 Сейчас в теме
(18) Немного не так. Точнее совсем не так. Он может ответить на вопрос, но только не в формулировке "Да/Нет". Т.е. он может ответить, что "Задание должно выполняться в фоне", но не может ответить на вопрос "Должно ли задание выполняться в фоне?" простым "Да" или "Нет". Вот в чем его особенность :)
20. boln 1044 08.08.17 18:38 Сейчас в теме
(19) А, ну тогда это нормально. Значит, у него просто пунктик какой-то на эти слова, вполне извинительный.
154. Andreeei 50 14.04.21 11:39 Сейчас в теме
(11) В фоне или нет должна работать обработка руководителю не интересно, это как программисту стандарт подскажет: https://its.1c.ru/db/v8std#content:642:hdoc:_top:%D1%84%D0%BE%D0%BD%D0%BE%D0%B2%D0%BE%D0%B5%20%D0%B2%D1%8B%D0­%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5
12. swimdog 798 08.08.17 14:30 Сейчас в теме
очепятка: Во-первый один раз я уже ошибся
13. swimdog 798 08.08.17 14:35 Сейчас в теме
>4. Если ошибся, то извинись, исправь и скажи почему такого больше не будет.

Это невозможно гарантировать. Все в этой жизни бывает, компьютеры ломаются, провода рвутся, самолеты опаздывают. Можно лишь стараться)
_Vanda_; AlexanderEkb; Neti; +3 – Ответить
14. Automatik 1015 08.08.17 14:57 Сейчас в теме
Напоминает скрам
15. natic18 08.08.17 16:36 Сейчас в теме
21. 1c-intelligence 13240 09.08.17 09:39 Сейчас в теме
Есть подозрение, что вы решаете задачу, которую решать не нужно. Задача - расчет сроков, управление сроками, управление по срокам.

На эту тему хорошо написал Голдратт в книге "Цель":
"Когда я работал преподавателем физики, люди время от времени приходили ко мне с математическими задачами, которые они не могли решить. Они хотели, чтобы я проверил их расчеты. Но в скором времени я научился не тратить время на проверку правильности цифр, потому что почти всегда цифры были правильные. А вот когда я проверял исходные посылки, они почти всегда оказывались ложными."

Здесь (и не только здесь, а повсеместно в управлении), неверная исходная предпосылка - "дайте срок". В 99% случаев нет никакой необходимости вычислять срок, укладываться в него, стремиться к нему. Это ошибка классического управления по срокам, очень распространенного в России. Есть хорошая формулировка, которая помогает понять, нужен ли жесткий срок - нужен он только тогда, когда по истечении срока работа будет не нужна.

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

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

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

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

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


Главное, самое важно и ценное, что мы, 1Сники, можем дать людям - это научить их задавать правильные вопросы. А вы предлагаете просто на вопросы отвечать.

Большинство, подавляющее большинство задач, которые ставят клиенты, решать не нужно. Самое поганое - когда клиент ставит задачу. А потом еще вопросы по ней начинает задавать. А программист под козырек и отвечает, не вдаваясь в объяснения. Это опять система ценностей такая - "быстро и четко отвечать на вопросы". Ответил - молодец. Не ответил - не молодец.

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

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

3. Постоянно контролируй ожидания клиента

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


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

Ожидания нужно не контролировать, а управлять ими. Менять их, иногда кардинально.

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

Выход попроще - научиться работать по скраму. В этом случае вы по-прежнему делаете много бесполезной для клиента работы, которую он сам попросил, но делаете это в 2-4 раза быстрее. Клиент перестанет спрашивать с вас сроки, вы перестанете париться насчет сроков. Он просто будет знать, что вы любую работу сделаете очень быстро и качественно.
Что интересно, результат будет совершенно неожиданный - при возросшей в разы эффективности вы будете легко, непринужденно и точно называть сроки работу. И чем дальше, тем эти сроки будут точнее. Ну и, главное, короче - и тех, что вы называете сейчас, и тех, что будут называть ваши конкуренты. И весь рынок тогда станет вашим.

Выход посложнее - понять цели бизнеса, происходящие в нем процессы, методы достижения успеха и место автоматизации в них. А потом - главное: научите этому клиента. Потому что 99% клиентов не знают, что и как надо сделать, чтобы стало лучше.

Тогда и у вас, и у клиента, и у вашей команды (если она есть) сформируется правильная система ценностей. Не надуманная, наподобие "укладываться в срок", а настоящая, наподобие "повышать прибыльность бизнеса" или, на худой конец, "стать лучшей командой автоматизации в стране".

Удачи!

P.S. Комментарий получился длинный, надеюсь будет полезен. По количеству слов почти догнал вашу статью (811 против 1002).
kalyaka; Rega; begemot; Kinestetik; RFP; greencactus2013; AlexanderEkb; UniversaLL; orfos; Артано; ZOMI; mindcannon; TreeDogNight; Neti; N2; Nelli_A86; alevnev; tgr123; Rjhev; MenZurKa; Anchoret; kuzyara; boln; TODD22; KapasMordorov; +25 –1 Ответить
23. PAVI 1389 09.08.17 10:40 Сейчас в теме
(21)
Программист в итоге работает очень неэффективно, т.к. его главная мысль, главное ограничение и цель - уложиться в срок.

Потрясающая мысль! Долой все сроки и ограничения! Если программист над одной маленькой задачкой будет работать месяц - замечательно! Так тому и быть! Правда, как быть с его зарплатой, которую он хочет получать в конкретных цифрах и к конкретному времени?!
Самое интересное то, что для определенных людей в определенные сроки этот посыл может сработать.
И еще интересно то, что программисты, в основном, математики. Но почему-то нам, психологам, преподавали математическое планирование эксперимента, а программисты обнаруживают явное отсутствие знакомства с этим предметом.
В общих чертах, все просто:
- определяем "базу" - с кем работаем;
- определяем цель - что хотим получить;
- определяем факторы, влияющие на достижение цели, долю их влияния и степень разброса результатов;
- планируем эксперимент по выборке, методам и предполагаемым результатам;
- проводим эксперимент и получаем подтверждение или опровержение своих теорий.

Вывод: статьи, подобные обсуждаемой, хороши тем, что будоражат мысль. Но они не могут быть "кодом поведения", как и их "опровержения".
Настоящее управление (и психология) - предметы достаточно сложные и точные, как и программирование )))
-
gmw; Rega; AlexanderEkb; Redokov; +4 – Ответить
24. 1c-intelligence 13240 09.08.17 10:47 Сейчас в теме
(23)
Если программист над одной маленькой задачкой будет работать месяц - замечательно!


Применительно к управлению по срокам эту фразу надо продолжить.
Вот полная фраза: Если программист над одной маленькой задачкой будет работать месяц - замечательно! Если мы ему такой срок поставили - месяц! Главное - чтобы в срок.

Ирина, вы - умный и опытный человек. Неужели вы именно так поняли мысль про сроки?
unknown181538; N2; +2 – Ответить
26. PAVI 1389 09.08.17 13:10 Сейчас в теме
(24)
Я "не открою Америку", если скажу, что большинство руководителей предпочитает предсказуемых сотрудников. И в этом плане гениальный работник, который абсолютно не умеет нормировать свой труд, будет проигрывать среднему, но вполне надежному по срокам сотруднику. Об этом и сказано в статье автора.
Вы же говорите (и очень красноречиво), что установка сроков в 99% случаев не нужна и
Есть хорошая формулировка, которая помогает понять, нужен ли жесткий срок - нужен он только тогда, когда по истечении срока работа будет не нужна.

Простите, но это абсолютно не применимо в экономике, базирующейся на производительности труда. А мы (пока?!) живем именно в это время.
НО! Смысл в Ваших утверждениях тоже есть, поэтому они и "цепляют". Просто "база" не та)))
gmw; Solovyeff; +2 – Ответить
28. 1c-intelligence 13240 09.08.17 13:25 Сейчас в теме
(26) Ирина, вы же не называете нормированием труда установку сроков исполнителю?
И не связываете умение называть и укладываться в сроки с производительностью труда?
31. PAVI 1389 09.08.17 14:24 Сейчас в теме
(28)
вы же не называете нормированием труда установку сроков исполнителю?
И не связываете умение называть и укладываться в сроки с производительностью труда?

Именно называю и связываю ))) А как иначе?
В программировании такое нормирование сложнее, чем иных производствах. Поэтому часто используется автонормирование (когда человек сам определяет свою производительность).
33. 1c-intelligence 13240 09.08.17 15:01 Сейчас в теме
(31) давайте разбираться.
Производительность, упрощенно - способность производить некое количество единиц в единицу времени.

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

Теперь вопрос: зачем нам спрашивать у программиста срок? Или зачем ему ставить срок?

Если мы все знаем о производительности программиста, а он сам не знает (мы ему не сказали), то в этом есть смысл - проверим, насколько он адекватно себя оценивает. Скажет "пятница" - врет, перестраховывается. Скажет "вторник" - переоценивает себя.

Но если и мы, и программист, знаем одно и то же - его производительность - зачем нам сроки?

Не проще дать ему список задач с оценками трудозатрат в единицах, расставить приоритеты, и сказать "реши как можно больше задач за неделю"?

А в конце недели посмотреть на объем решенных задач в наших единицах, и понять эффективность программиста? Сделал 25 единиц в неделю - молодец. Сделал меньше - не молодец. Сделал 40 - иди сюда, расскажи, как тебе это удалось, мы применим твои компетенции для других программистов.

Заодно обеспечить ему комфортную среду и наблюдать за его работой в течение недели, помогая преодолевать ступор, который ведет к иссяканию потока решенных задач?

Где здесь место практикам типа "назови мне срок"?

Обычно же ситуация намного проще. Менеджер понятия не имеет, какая у программиста производительность, и не пытается ее узнать, продолжая оценивать работу по попаданию в срок. Разве нет?
gmw; RFP; TreeDogNight; +3 – Ответить
35. PAVI 1389 09.08.17 15:58 Сейчас в теме
(33)
Мы знаем, что программист производит 5 единиц работы в день.
Ставя ему утром понедельника задачу, которая содержит 15 единиц работы, мы понимаем, что решения надо ждать в конце среды.

Где-то здесь, на просторах Инфостарта, есть видео о том, что проблема выбора приводит программиста (и не только) к тому, что время выполнения трех работ приводит к увеличению времени выполнения по сравнению с суммой времени на каждую работу, выданную отдельно.
Но теперь по сути.
Стандартизировать работу программиста сложно по ряду причин
- разный уровень владения предметом при кадровом дефиците заставляет менеджеров работать с теми, кто есть;
- зоопарк программных продуктов на рынке и у клиентов (даже одной фирмы-производителя) усиливает кадровую проблему; почти невозможно иметь в штате сотрудников, одинаково хорошо владеющих 7.7 и 8.3, плюс знающих предметные области от бюджетирования до маркетинга;
- встречающиеся в программах ошибки и "недокументированные особенности" могут превратить разработку заурядного отчета в "битву титанов";
- люди с сильным и слабым типом нервной системы работают по-разному (кто-то быстро включается, но и быстро отвлекается, кто-то включается в работу долго, но потом прет...)
- человек никогда не работает больше, если можно работать меньше.
Проще справляется с этой проблемой Белов: сроки + качество обеспечат тебе и в дальнейшем заказами.
Поэтому "самое лучшее, что мы можем для себя сделать - это познакомиться с собой по-настоящему" сказала Черниговская Татьяна Владимировна (российский ученый в области теории сознания).
P.S. Так получилось, что работая с мужем-программистом, я уже двадцать лет пытаюсь отвечать на вопросы менеджеров разного уровня что и к какому сроку будет сделано)))
gmw; YanTsys; +2 – Ответить
36. 1c-intelligence 13240 10.08.17 06:58 Сейчас в теме
(35)
проблема выбора приводит программиста (и не только) к тому, что время выполнения трех работ приводит к увеличению времени выполнения по сравнению с суммой времени на каждую работу, выданную отдельно


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

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

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

Стандартизировать надо не работу программиста, а цифровую оценку задач. Тогда все встанет на свои места.

Вам доводилось работать по скраму или видеть воочию, как это делают другие?
38. genayo 10.08.17 08:33 Сейчас в теме
(36) Расскажите конкретно о вашем понимании скрама и как оно работает на практике. Если просто писать общие слова - вас никто не поймет. Если не можете рассказать - лучше не упоминайте об этом.
39. 1c-intelligence 13240 10.08.17 09:08 Сейчас в теме
(38) рассказать мое понимание зачем? Вы оцените, правильно я понял или нет?

Если не можете рассказать - лучше не упоминайте об этом

Спасибо за совет.

Мое понимание скрама началось на английском названии книги - Scrum: The Art of Doing Twice the Work in Half the Time. Скрам - это делать в разы больше за то же время и теми же ресурсами. Детали - внутри.

Я правильно понял?
40. genayo 10.08.17 10:10 Сейчас в теме
(39) Нет, мне интересно, как практически применяются все те умные слова, которые написаны в умных книжках. Вы говорите, что у ваших оппонентов неправильный подход, но при этом не рассказываете, какой подход используете вы, отделываясь общими фразами.
43. 1c-intelligence 13240 10.08.17 10:33 Сейчас в теме
(40) спасибо. Это то, что нужно.
Рассказывать буду на Event 2017 (http://event.infostart.ru/2017/agenda/#item644119), если пустят.
Если не пустят - напишу статью.
TreeDogNight; Neti; +2 – Ответить
74. PAVI 1389 11.08.17 11:00 Сейчас в теме
(43)
Я проголосовала за Ваш доклад, хотя и без моей поддержки Вы входите в квоту. Надеюсь, что те вопросы и замечания, которые здесь "прозвучали" будут учтены в докладе. Хотя некоторые докладчики хотят быть не понятыми, а услышанными )))
75. 1c-intelligence 13240 11.08.17 11:03 Сейчас в теме
(74) да, в этот раз доклад будет о практике и результатах, которые она принесла.
Ну а если уж останется время, то о философии - почему так.
41. alex_sh2008 5 10.08.17 10:22 Сейчас в теме
(36)
Работу программиста стандартизировать, наверное, сложно. Это такая же задача, как научиться называть точный срок - сложная и, главное, бессмысленная.

Как ни странно работа программиста уже давным давно стандартизирована, но судя по тезисам у программистов 1С нет ни каких стандартов.
42. 1c-intelligence 13240 10.08.17 10:31 Сейчас в теме
(41) наверное, ваш комментарий правильнее адресовать Ирине.
Я ничего не знаю про стандартизацию работы программистов, поэтому и написал
Работу программиста стандартизировать, наверное, сложно.
45. alex_sh2008 5 10.08.17 11:14 Сейчас в теме
(42)Но вы же акцентирует свою статью именно на программистов, хотя рассуждаете совсем в другом направлении, которое косвенно относится к программистам.
47. 1c-intelligence 13240 10.08.17 11:16 Сейчас в теме
(45) не понял, какую статью акцентирую?
48. alex_sh2008 5 10.08.17 11:19 Сейчас в теме
(47)Сорри, не правильно выстроил предложение: "обсуждаете"
49. 1c-intelligence 13240 10.08.17 11:30 Сейчас в теме
(48) вы про производительность? или про скрам? или про управление по срокам?
Что из этого косвенно относится к программистам?
50. alex_sh2008 5 10.08.17 11:36 Сейчас в теме
(49) Все косвенно относится к программистам, в статье акцент на взаимоотношения между заказчиком и исполнителем. Всякие там скрамы, управления сроками, все это ерунда, если вы не можете выстроить горизонтальный диалог с заказчиком.
51. 1c-intelligence 13240 10.08.17 11:46 Сейчас в теме
(50) всякие там скрамы, управления сроками - это как раз про горизонтальный диалог с заказчиком. Про то, как этот диалог ведется, и какова его эффективность - для вас и для заказчика.

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

Диалог - это коммуникационный канал. Благодаря ему появляется поток ценностей. Заказчик получает автоматизацию, вы получаете деньги.

Все, что мы тут обсуждаем - как сделать этот канал толще. Чтобы заказчик получал больше полезного, а вы больше денег.

"Канал толще" = "канал производительнее". Отсюда - обсуждение производительности. И методов соответствующих.

Что не так?
RFP; TreeDogNight; +2 – Ответить
52. alex_sh2008 5 10.08.17 11:48 Сейчас в теме
(51)При том что это уровень не программиста.
53. Rjhev 294 10.08.17 11:53 Сейчас в теме
(52) Согласен.
Это уровень не программиста, а 1с-ника.
tailer2; TreeDogNight; OneScan; SunShinne; +4 – Ответить
54. alex_sh2008 5 10.08.17 11:56 Сейчас в теме
(53)Руководство не оперирует информационными системами, а оперирует бизнес-процессами, функциональностью, целями, требованиями. И им все равно что там ниже этого, 1С или другая система.
55. Rjhev 294 10.08.17 12:03 Сейчас в теме
(54) 1с-ник зачастую исполнитель, консультант, программист и внедренец в одном флаконе.
Поговорил с Заказчиком на его языке, для себя набросал план, провёл обследование, скорректировал план, проконсультировался с ключевыми пользователями, по результатам пообщался с Заказчиком, опять же на его языке.

Так что приходится знать, что такое "крыжить", "осальдовка", "KPI", scrum, IDEF0 и управление требованиями.
57. 1c-intelligence 13240 10.08.17 12:10 Сейчас в теме
(54) дак и нам вроде все равно, что там ниже этого.

Все, к чему я призываю 1Сников - тоже оперировать "бизнес-процессами, функциональностью, целями, требованиями".

А не пытаться научить руководителей оперировать регистрами, УФ, отчетами и обработками.

Это проще, чем кажется. И, главное, это почти единственный вариант. 1Сник быстрее и лучше поймет "бизнес-процессы, функциональность, цели, требования", чем руководитель поймет регистры, УФ, отчеты и обработки.

Понимаете? С нашей стороны (снизу, если вам так больше нравится) шагнуть навстречу заказчику легче, чем ему спускаться к нам.
Solovyeff; TreeDogNight; Rjhev; +3 – Ответить
61. alex_sh2008 5 10.08.17 14:35 Сейчас в теме
(57)
Понимаете? С нашей стороны (снизу, если вам так больше нравится) шагнуть навстречу заказчику легче, чем ему спускаться к нам.

Подыматься ни чуть не легче чем спускаться, нужно получить достаточный объем знаний, в конце концов придется встать перед выбором либо одно либо другое, совместить это не получится.
63. 1c-intelligence 13240 11.08.17 05:33 Сейчас в теме
(61) объем знаний небольшой, уверяю вас, и достаточно увлекательный.
И вполне совместимый с душой 1Сника.
UniversaLL; KapasMordorov; TreeDogNight; +3 – Ответить
67. alex_sh2008 5 11.08.17 09:09 Сейчас в теме
(63)Для "ларьков" может и не большой, но для серьезных проектов очень даже большой
69. 1c-intelligence 13240 11.08.17 09:11 Сейчас в теме
(67) не буду пытаться вас переспорить, не дай Бог удастся, вы информацию изучите и станете конкурентом.
71. alex_sh2008 5 11.08.17 09:15 Сейчас в теме
(69)Ну скажем так я учусь этому постоянно, и не только в направлении 1С. Круг задач очень обширный. Сопровождать целую ИТ инфраструктуру на производственном предприятии требует много усилий.
56. 1c-intelligence 13240 10.08.17 12:06 Сейчас в теме
(52) хм... почему?

Это вроде ваш личный выбор, на каком уровне быть.

Фрилансер 1Сник - он кто? У него продажи есть? Деньги? Надо, чтобы их больше стало?

Сотрудник франча, который на сделке, захочет решать вдвое больше задач за рабочий день, чтобы получать вдвое больше денег?
62. alex_sh2008 5 10.08.17 14:40 Сейчас в теме
(56)Вот из за этих факторов, в 1С мало профессиональных программистов, по сравнению к примеру Java, C#, С++.
64. 1c-intelligence 13240 11.08.17 05:34 Сейчас в теме
(62) думаю, нам, 1Сникам, было бы интересно узнать, кто такие профессиональные программисты, и чему у них можно научиться.
mytg; Rjhev; TreeDogNight; +3 – Ответить
66. alex_sh2008 5 11.08.17 09:08 Сейчас в теме
(64)Скачиваете исходные коды, к примеру opensource ERP, притом лучше что бы они были написаны на разных языках, и изучаете их, то как структуируется код, связывается друг с другом и другие вещи. Как правило эти все продукты пишут те же самые разработчики что и пишут платные продукты. Как вариант проект VMware Alfresco
68. 1c-intelligence 13240 11.08.17 09:10 Сейчас в теме
(66) есть другие способы, кроме изучения исходного кода?
И есть ли другие признаки профессиональных программистов, кроме исходного кода?
91. tailer2 11.08.17 12:23 Сейчас в теме
(41) 1снег - не программист, по крайней мере не в том смысле, которого стандартизуют
72. PAVI 1389 11.08.17 10:41 Сейчас в теме
(36) Любая научная или научно-популярная работа начинается с определений. Вот выдержки из Ваших постов:
Стандартизировать надо не работу программиста, а цифровую оценку задач. Тогда все встанет на свои места.

дать ему список задач с оценками трудозатрат в единицах,

Если цифровая оценка задач НЕ РАВНА стандартизированной работе программиста, то почему Вы снова пишете об "оценке трудозатрат"?!
Я хочу понять Вас, тема для меня интересная))
73. 1c-intelligence 13240 11.08.17 10:52 Сейчас в теме
(72) я когда услышал про стандартизацию работы программиста, мне стало не по себе.
Сразу перед глазами возник сложный, запутанный бизнес-процесс, предписывающие обязательные шаги, точки принятия решений и тому подобное.
Заниматься такой стандартизацией, как мне кажется, дело неблагодарное.

Цифровая оценка задач - намного проще.
Лично я использую покер планирования. Быстро и эффективно дает оценку задачи в виде цифры.
И вроде стандартизировать не нужно, правила просты.

А дальше все проще и интереснее, когда есть цифры.
76. PAVI 1389 11.08.17 11:10 Сейчас в теме
(73)
Цифровая оценка задач - намного проще.
Лично я использую покер планирования. Быстро и эффективно дает оценку задачи в виде цифры.

Класс! Дать определение с помощью другого непонятного определения - это один из способов манипуляции сознанием собеседника.
Похоже, что Ваше высказывание:
"не дай Бог удастся, вы информацию изучите и станете конкурентом"
не шутка, а принцип изложения информации. Жаль(((
Rjhev; genayo; +2 – Ответить
78. 1c-intelligence 13240 11.08.17 11:25 Сейчас в теме
(76) прошу прощения. Цели манипулировать вашим сознанием у меня не было.
Честно полагал, что вы знаете о покере планирования.
Это практический прием оценки задач в скраме.

Выполняется примерно так:
1. Оценивают все участники команды, которые способны понять конкретную задачу;
2. Оценивают с помощью карт, на которых написаны цифровые оценки. Оценки - из урезанного ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21 и т.д.);
3. Если оценки разошлись дальше, чем на один элемент ряда (например, 3 и 8), то задача обсуждается еще раз, т.к. кто-то чего-то не понял;
4. Итоговая оценка рассчитывается как средняя.
UniversaLL; +1 – Ответить
79. genayo 11.08.17 11:37 Сейчас в теме
(78) Очевидно, это будет работать, когда в команде специалисты примерно одинакового уровня, и конкретная задача имеет только технические аспекты, понятные всем программистам.
80. 1c-intelligence 13240 11.08.17 11:43 Сейчас в теме
(79) не совсем так. Если все одного уровня и задача имеет только технические аспекты, то сходимость результата будет выше, и оценка будет получаться почти всегда за одну итерацию.
Но получение оценки за одну итерацию - это не цель, и не положительный результат.

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

В классике этот метод - для кроссфункциональных команд.
83. PAVI 1389 11.08.17 11:53 Сейчас в теме
(80)
то сходимость результата будет выше,

Порадовали термины статистической оценки достоверности результатов)))

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

Да-с-с... Я пару раз работала на проектах с ребятами, которые до 1С-овских проектов служили в Генштабе. Их оценка трудоемкости просто лишала дара речи...
И еще один пример из жизни: на крупном проекте пришлось переделывать работу коллег из своей же фирмы. Мы с руководителем проекта разошлись в оценке трудоемкости по переделке одной из основных форм. Чтобы убедиться в том, что права я, ему пришлось несколько часов пытаться решить задачу.
Кстати, как бы ни назывались все эти методы оценки трудоемкости (хоть и замаскированной под другую оценку), смысл везде один "строго на глаз"
94. 1c-intelligence 13240 11.08.17 12:32 Сейчас в теме
(83) уверен, вы понимаете: главное - результат.
Если метод оценки помогает достичь результата и его систематического улучшения, то неважно, на глаз он или нет.
Если просто смотреть на метод, то ни черта не понятно, сработает он или нет.
Это, говоря в терминах соседней статьи, эмерджентное свойство системы.
85. genayo 11.08.17 12:01 Сейчас в теме
(80) Это что, получается чтобы адекватно оценить срок выполнения задачи, нужно еще с кучей людей, которые эту задачу делать не будут, несколько раз эту задачу обсудить? Вот стоит у меня сейчас задача интеграции WMS на 1С c SAP, я что, должен чтобы назвать точный срок выполнения, обсудить её с программистом, который сейчас внедряет Бит-Финанс?
88. 1c-intelligence 13240 11.08.17 12:17 Сейчас в теме
(85) это как сами решите.

должен чтобы назвать точный срок выполнения


мы тут начали с того, что не надо называть точные сроки выполнения :)
Оценка задач в цифрах - не для точного угадывания сроков. Она для системы координат, на которой можно построить ускорение работы команды.

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

Ну и слово "должен" тут неуместно. "Могу" больше подходит. Главное, чтобы польза была.
А гибкость поможет. Взяли в команду оценки всех, попробовали - ерунда. Выгнали всех, остались в одиночестве, попробовали - опять ерунда. Взяли двоих, попробовали - о, вроде получилось. Все, у вас свой, подходящий под контекст, метод оценки задач.
97. genayo 11.08.17 12:35 Сейчас в теме
(88) Вот, правильные мысли. Если вы предлагаете какое-то свое решение, нужно рассказывать не только о преимуществах, но и об ограничениях применимости. Вы же этот вопрос в своих статьях обычно опускаете, не знаю, умышленно или нет.
101. 1c-intelligence 13240 11.08.17 12:41 Сейчас в теме
(97) к сожалению, я предлагаю не свои методы, а подходы, на основе которых я создал свои методы.
Метод - компиляция подхода, или даже шаблона метода, и конкретной среды.

Ровно так, как сказал Голдратт (да простят меня нелюбители цитат):
"Есть разница между прикладными решениями (применениями) и фундаментальными концепциями, на которых основаны эти решения. Концепции являются общими, прикладные решения - это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой и делает необходимой разработку определенных элементов решения. Мы должны помнить - прикладное решение основано на исходных посылках (иногда - скрытых) о конкретной среде. Не надо ожидать, что это прикладное решение будет работать в среде, для которой исходные посылки не верны".

Если я при оценке задач советуюсь с цеховым бухгалтером, то вам я этого посоветовать не могу. Упомянуть - да, но советовать - нет.
104. genayo 11.08.17 12:46 Сейчас в теме
(101) Вот и ладно. Теперь мне все понятно, дальнейшая дискуссия бессмысленна.
108. 1c-intelligence 13240 11.08.17 13:00 Сейчас в теме
(104) это уже не важно.
Вы - очень толковый и полезный собеседник, и состоявшаяся дискуссия принесла много пользы.
Удачи!
105. PAVI 1389 11.08.17 12:46 Сейчас в теме
(88)
мы тут начали с того, что не надо называть точные сроки выполнения :)
Оценка задач в цифрах - не для точного угадывания сроков. Она для системы координат, на которой можно построить ускорение работы команды.

Наверное главное, что мешает мне Вас понять - это то, как Вы, придя к потенциальному клиенту, будете ему объяснять, что сроков выполнения работ вы ему называть не будете совсем, сделаем, когда сможем. Так и слышу ответ: "Тогда мы не будем вам называть суммы финансирования работ. Заплатим, сколько сможем".

Я не против Вашей методики. У каждого есть свой любимый инструмент. Я против того, что часто изобретают "таблетку от всех болезней".
Я за то, чтобы описывая метод, описывали не только его сильные стороны, но и ограничения, которые неизбежны. Чем навязчивее реклама, тем больше шансов, что продукт ей не совсем соответствует...
Мир состоит из света и тени. Тем ценнее статья автора, в комментариях к которой мы "резвимся", что она имеет и "свет", и "тень" ))).
gmw; YanTsys; +2 – Ответить
109. 1c-intelligence 13240 11.08.17 13:14 Сейчас в теме
(105) в данном конкретном случае я рекламирую не свой метод, а скрам.
Моя неверная предпосылка - я думал, что все хорошо знают, что такое скрам, и применяли его на практике. Из-за этой неверной предпосылки я стал предлагать/обсуждать конкретный элемент скрама - покер планирования. И долго не понимал, что я непонятного говорю.
112. alex_sh2008 5 11.08.17 13:24 Сейчас в теме
(109)А что такое скрам расскажите своими словами что бы это поняли обычные люди без особых знание терминов и технологий управления проектами.
115. Rjhev 294 11.08.17 15:24 Сейчас в теме
(112)
А что такое скрам расскажите своими словами что бы это поняли обычные люди без особых знание терминов и технологий управления проектами.

А про это рядом висит отдельная статья

ну и связанные ссылки на инфостарте:
https://infostart.ru/video/w530493/

https://infostart.ru/public/329173/

https://infostart.ru/public/318229/

https://infostart.ru/public/377535/

https://infostart.ru/public/648073/
116. alex_sh2008 5 11.08.17 16:29 Сейчас в теме
(115)Это я и сам могу прочитать, и не только отсюда, но и из первоисточников. Вопрос был в другом
117. Rjhev 294 11.08.17 16:32 Сейчас в теме
(116) ну, как написал, так и получил.
в (112) режет глаз отсутствие запятых и наплевательство на ошибки.
119. alex_sh2008 5 11.08.17 16:43 Сейчас в теме
(117)Написал простым языком в манере общения, вы прекрасно поняли что я хотел, но полезли в сторону.
118. PAVI 1389 11.08.17 16:32 Сейчас в теме
(115) Первая ссылка сюда
Управление проектами по Scrum
привела к статье, которая представляет scrum, как "компот" из методик управления, обрывков восточной философии, религии и немного "волшебства". Приверженцы таких "компотов" часто фанатики и логику понимают плохо. "Верую, ибо нелепо".
Провокации видны сразу:
"Что для вас важнее: процессы или люди?" - это кто же осмелится не сделать выбор в пользу людей?!
Можно сразу ставить жирный крест на бизнес-процессах любого рода.
Но чуть более глубокое знакомство с восточной или европейской философией приводит к закону о единстве и борьбе противоположностей. У китайцев даже символ есть "Инь-Ян".
,,, Придется покопаться в этом популярном течении поглубже...
120. alex_sh2008 5 11.08.17 16:45 Сейчас в теме
(118)Можно сколько угодно перечитать книжек, это ничего не изменит, если саму идею не понять, ее не возможно выразить своими словами.
121. PAVI 1389 11.08.17 16:47 Сейчас в теме
(120)
Вот и это признак религии... Грустно(((
122. genayo 11.08.17 17:34 Сейчас в теме
(120) Как говаривал великий кормчий Мао, сколько книжек не читай - умнее не будешь...
125. boln 1044 11.08.17 21:53 Сейчас в теме
(122)
Как говаривал великий кормчий Мао, сколько книжек не читай - умнее не будешь...
Ну правильно, Мао не читатель, Мао писатель :)
89. TODD22 20 11.08.17 12:19 Сейчас в теме
(85)
обсудить её с программистом, который сейчас внедряет Бит-Финанс?

Если работа одних, зависит от работы других то почему нет?
Делать то может не будут. Но от результатов работы одних, может зависеть результат работы других....
99. alex_sh2008 5 11.08.17 12:39 Сейчас в теме
(85)Нет, вы должны согласовать эту задачу с другим программистом, который будет реализовывать алгоритм интеграции.
102. genayo 11.08.17 12:41 Сейчас в теме
(99) С самим собой чтоли? Ну ладно, обсужу.
107. alex_sh2008 5 11.08.17 12:56 Сейчас в теме
(102)Ну если так то придется, стать на время программистом со всеми тараканами, капризами, и т.д.
81. PAVI 1389 11.08.17 11:43 Сейчас в теме
(78)
Иными словами, это принцип "самонормирования", совмещенный с оценкой "фокус-группы".
Думаю, что этот метод (прием) оценки трудоемкости задач страдает теми же недостатками, которые я описала в посте 35.
Плюс набрать "фокус-группу"... Тоже проблема.
82. 1c-intelligence 13240 11.08.17 11:50 Сейчас в теме
(81) я пользуюсь этим методом 2 года. Сначала были трудности - хотел разложить структуру оценки сложности, как-то ее классифицировать, алгоритмизировать, учесть риски отсутствия компетенций.
Потом дошло, что эффективность метода - в простоте. Простота становится ограничением и системой координат.

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

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

В итоге оказалось, что его оценки обычно даже ниже остальных, т.к. парень он умный, как решить задачу - знает, но характер такой видимо - негативист.
84. PAVI 1389 11.08.17 11:55 Сейчас в теме
(82)
характер такой видимо - негативист

Я бы сказала "пессимист". А как известно "пессимист - это информированный оптимист" )))
92. 1c-intelligence 13240 11.08.17 12:27 Сейчас в теме
(84) да, ваше определение точнее.
77. alex_sh2008 5 11.08.17 11:12 Сейчас в теме
(73)
я когда услышал про стандартизацию работы программиста, мне стало не по себе.

Стандартизация работы программиста включает в себя много факторов, включая распорядок дня. Программисты во время работы настолько уходят в задачу, что перестают замечать все вокруг, что сказывается и на качестве кода и на производительности.
96. 1c-intelligence 13240 11.08.17 12:35 Сейчас в теме
(77) уверен, что стандартизация включает в себя много факторов.
Меня один вопрос мучает - зачем? Какова цель стандартизации работы программиста?
Может, у вас есть ссылки на материалы, где об этом хорошо написано?
98. genayo 11.08.17 12:37 Сейчас в теме
(96) Цель стандартизации - нанять 100 дешевых индусов, и получить результат, похожий на работу 10 дорогих профессионалов. Это, кстати, почти во всех отраслях так...
103. 1c-intelligence 13240 11.08.17 12:44 Сейчас в теме
(98) тогда я против стандартизации.
Я за самостандартизацию. Дать людям цель и ограничения, они сами сделают себе стандарты.
106. alex_sh2008 5 11.08.17 12:48 Сейчас в теме
(96)
Меня один вопрос мучает - зачем? Какова цель стандартизации работы программиста?

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

Ссылок нет, я читал это в книгах, по управлению проектами, названия не вспомню было это в 2005
110. 1c-intelligence 13240 11.08.17 13:17 Сейчас в теме
(106) а если нет такой задачи - "чтобы смена программистов не повлияла на проект в целом, а стиль и структура кода не менялась на всем ...." - стандартизация не нужна?

Или она еще какие-то полезные выхлопы дает, кроме перечисленных?
111. alex_sh2008 5 11.08.17 13:22 Сейчас в теме
(110)Ну если вы пишет приложение с объемом до 10тыс строк, то может быть и прокатит. А вот когда напишите код объемом более 100тыс строк, и без стандартизации, увидите насколько сложно это все поддерживать, изменять, дописывать. Поэтому я вам и предложил посмотреть источники opensource проектов, они пишутся в одном стиле на протяжении 10 лет, и не важно кто вносит изменения в код, они придерживается тех правил которые были заданы на начальном этапе.
113. 1c-intelligence 13240 11.08.17 13:24 Сейчас в теме
(111) вы вроде сейчас про стандартизацию кода говорите. С этим я не спорю.
Я может не так понял, но вы говорили о стандартизации работы, т.е. процесса.
114. alex_sh2008 5 11.08.17 13:26 Сейчас в теме
(113)Это она и есть, я же говорил она включает в себя множество факторов. Бизнес процесс это не только задачи и действия, это еще и правила, регламенты, требования.
128. 1c-intelligence 13240 14.08.17 06:51 Сейчас в теме
(114) (116) (118) (120) (121)

Главное, что нужно узнать о скраме, заключено в названии книги: The Art of Doing Twice the Work in Half the Time. По-русски примерно так: искусство делать вдвое больше работы за половину времени.

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

Если вы видите людей, которые говорят - мы работаем по скрам, выберите нас - смело спрашивайте их: во сколько раз вы быстрее достигаете результата, чем "классические" команды?

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

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

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

Если вы беретесь за скрам, то помните о цели - ускорении в разы. Это суть, смысл и самое главное.

Я бегло просмотрел ссылки из (115), но не нашел там цифр - как выросла производительность команд. Если вы заметили там такие цифры, поправьте меня, буду признателен. Я некоторое время назад задавался целью найти реальные цифры, как ускоряются команды на скраме, но не смог. Если, опять же, у вас есть ссылки на такие материалы, буду признателен.

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

Дальше дело за вами, точнее - за скрам-мастером. Скрам-мастер должен увидеть, где команда теряет скорость, и внести соответствующие изменения в ее работу.
И да, это восточная философия. Философия управления качеством, распространенная и развитая на востоке - в Японии. Ровно об этом и написано в книге.

Лично я за 2 года получал ускорение в 3.25 раза. Но ясно вижу, что можно больше, просто не хватает дисциплины.
129. alex_sh2008 5 14.08.17 08:42 Сейчас в теме
(128) Я вроде задавал просто вопрос, и хотел услышать простой ответ, который укладывается в одном предложении, а вы по написали текста с пол. страницы.
130. 1c-intelligence 13240 14.08.17 08:58 Сейчас в теме
(129) я не думал, что вы это серьезно. Наверное, есть глубокий смысл в таком упражнении.
Попробую одним предложением.
Скрам - философия, позволяющая делать работу в 4 раза быстрее.
131. KapasMordorov 418 14.08.17 09:10 Сейчас в теме
(130)
Командную работу или для одиночки тоже есть применение?
133. 1c-intelligence 13240 14.08.17 09:18 Сейчас в теме
(131) для одиночки даже проще.
135. alex_sh2008 5 14.08.17 09:22 Сейчас в теме
(131)Одиночки кроме как по "scrum", по другому не смогут работать, у них просто ресурсов не хватит, ни физических, ни финансовых. И по большому они всегда так работали, даже тогда когда эту работу еще не выделили в отдельную методологию.
132. alex_sh2008 5 14.08.17 09:14 Сейчас в теме
(130)
Скрам - философия, позволяющая делать работу в 4 раза быстрее.

Но в проекте важна не только скорость, но и выпуск готового продукта, а не полуфабриката.
134. 1c-intelligence 13240 14.08.17 09:19 Сейчас в теме
(132)
выпуск готового продукта, а не полуфабриката

для простоты считайте, что на выходе - то же самое, что вы даете сейчас. Только в 4 раза быстрее.
136. alex_sh2008 5 14.08.17 09:25 Сейчас в теме
(134)Я бы с удовольствием по считал, но заказчик редко когда так считает, и ему не нужны хорошо отлаженный куски, а нужен готовый функционал. По "scrum" хорошо дописывать уже готовый продукт, но когда вы пишите все с нуля, очень сложно посчитать когда же вы все таки выйдете на готовый функционал, и выйдете ли вообще на него.
137. 1c-intelligence 13240 14.08.17 09:45 Сейчас в теме
(136) вы уже пробовали по скраму работать?
138. alex_sh2008 5 14.08.17 09:48 Сейчас в теме
(137)Сколько себя помню, а точнее около 15 лет работаю, и лишь иногда по типовой методике, когда есть финансирование и время, что бы написать требуемую бизнес модель и потом перейти на наращивание и исправление ошибок.
139. alex_sh2008 5 14.08.17 09:59 Сейчас в теме
(130)По пробуйте еще раз выразить своими словами, то как вы сами понимаете что такое "scrum", не ссылаясь ни на что, а только на ваш личный опыт и знания.
140. 1c-intelligence 13240 14.08.17 10:05 Сейчас в теме
(139) раз вы 15 лет работаете по скраму, то интереснее вашу формулировку услышать.
Я потерял цель нашего с вами упражнения, если честно.
141. alex_sh2008 5 14.08.17 10:09 Сейчас в теме
(140)Цель очень проста, понять (осознать) суть методики и применить ее к своей ситуации, а не скопировать и тупо следовать. моя формулировка очень проста: "Разработка по событию"
142. 1c-intelligence 13240 14.08.17 10:16 Сейчас в теме
(141) а как теперь разобраться, чья формулировка лучше?
143. alex_sh2008 5 14.08.17 10:22 Сейчас в теме
(142)Ни как, главное что бы вы осознавали что это такое, могли без копирки применять, изменять, дорабатывать, совмещать. С мое точки зрения ваша формулировка относится больше к результатам чем к самому процессу как таковому. Одинаковый результат можно получить, что по "scrum", что по плоской модели разработки. И опять же выбор за вами, я не претендую на первое место в гонке за рейтинг, кто круче по "scrum".
144. 1c-intelligence 13240 14.08.17 10:23 Сейчас в теме
(143) вы, работая по скрам, достигаете результата быстрее?
145. alex_sh2008 5 14.08.17 10:35 Сейчас в теме
(144)Смотря как смотреть на это, локальные проблемы я решаю быстрее, не трачу свое время на менее кричных проблемах. Но в целом с точки зрения проекта целиком, долго выхожу на финиш. Но фактически мне не нужно выходить на финиш, приложения уже внедрены и работают, много лет.
148. 1c-intelligence 13240 14.08.17 19:31 Сейчас в теме
(145) если дать вам 100 небольших задач (не больше 1 дня на разработку) по улучшению текущей системы, все это мероприятие назвать проект, вы сделаете это быстрее скрамом или каскадом?
149. 1c-intelligence 13240 14.08.17 19:32 Сейчас в теме
(145) забыл главное спросить: вы измеряли скорость и ускорение своей работы, когда применяли скрам?
150. alex_sh2008 5 14.08.17 20:25 Сейчас в теме
(149)Не было самоцели, сравнить
151. 1c-intelligence 13240 15.08.17 05:17 Сейчас в теме
(150) понятно, спасибо.
87. tailer2 11.08.17 12:15 Сейчас в теме
(35)
Татьяна Черниговская: «Не доверяй примитивным поисковикам, задай вопрос миру!»


чо :)

Мы такие, какие есть, потому что у нас такое тело.


нет
у нас (не потомков обезиан) такое тело потому что мы
153. gmw 7 20.06.20 17:38 Сейчас в теме
(35)
- человек никогда не работает больше, если можно работать меньше.

1. Если этот человек не смотрит на работу как на творчество.
2. Если он не заинтересован в развитии участка или направления, на котором работает.
3. Если человек видит в работе лишь способ добыть деньги.
Думаю, что не все программисты подходят под эти критерии.
25. KapasMordorov 418 09.08.17 11:10 Сейчас в теме
(23)
Ну пусть сначала у всех программистов зарплата начнет зависеть от решенных в срок задач. И тогда всё это можно отдать в психологию -
точный предмет
.
А если коротко: "база"-то у вас и маловата.
27. PAVI 1389 09.08.17 13:18 Сейчас в теме
(25)
Мы же говорим не о "кухонной" психологии, в которой "разбираются" все, а о фундаментальной науке.
Но, простите за непонятливость, какая именно "база" у меня маловата? Это при моем 54-м размере?))
30. Rjhev 294 09.08.17 14:01 Сейчас в теме
(23)
Если программист над одной маленькой задачкой будет работать месяц - замечательно! Так тому и быть!

Программист вообще может за месяц не решить "ни одной маленькой задачки" и получить за это премию.
Показав, как нужная пользователю задача решается имеющимся функционалом.
Настроив отчет так, чтобы видеть нужные данные.
Объяснив, как менеджеру, кладовщику и бухгалтеру работать в их программе.
YanTsys; mindcannon; TreeDogNight; +3 – Ответить
32. PAVI 1389 09.08.17 14:25 Сейчас в теме
(30)
Показав, как нужная пользователю задача решается имеющимся функционалом.
Настроив отчет так, чтобы видеть нужные данные.
Объяснив, как менеджеру, кладовщику и бухгалтеру работать в их программе.

Это уже несколько маленьких задачек, если программист выполняет еще и функцию методиста )))
58. Neti 2647 10.08.17 12:14 Сейчас в теме
(21)
Спасибо. Очень хорошее дополнение.
Читал книги Голдратта. Там реально полезные и правильные идеи.

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

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

Ещё раз спасибо за дополнения!
SunShinne; +1 – Ответить
59. 1c-intelligence 13240 10.08.17 12:22 Сейчас в теме
(58) спасибо.
С удовольствием почитаю вашу следующую статью и помогу ей подержаться на главной странице инфостарта :)
SunShinne; Neti; +2 – Ответить
86. tailer2 11.08.17 12:04 Сейчас в теме
(21)
можем дать людям - это научить их задавать правильные вопросы

можем
но они нас об этом не просят
и не за это платят

Клиент, с высокой вероятностью, ждет от вас совсем другого


если вы лучше клиента знаете, что он хочет,
вы можете заплатить себе сами за его обучение
90. 1c-intelligence 13240 11.08.17 12:20 Сейчас в теме
(86) они вам не за это платят и об этом не просят, потому что не знают, что вы это умеете.
По вашим постам видно, что умеете.

(86)
если вы лучше клиента знаете, что он хочет,
вы можете заплатить себе сами за его обучение


верно подмечено. Это называется "инвестиции".
93. tailer2 11.08.17 12:30 Сейчас в теме
(90) ага
а еще деньги - это доллары, евро и рубли
до ближайшей реформы павлова
95. 1c-intelligence 13240 11.08.17 12:33 Сейчас в теме
(93) мысль вашу не понял, но звучит убедительно.
123. tailer2 11.08.17 18:05 Сейчас в теме
(95) ничего страшного
госдумецы тоже не понимают, но законы пишут
124. 1c-intelligence 13240 11.08.17 18:29 Сейчас в теме
(123) вы им тоже сообщения пишете, и они говорят, что ничего не поняли, но продолжают писать законы?
146. tailer2 14.08.17 16:06 Сейчас в теме
(124) они просто пишут, вне зависимости от чего-либо
22. gull22 106 09.08.17 09:47 Сейчас в теме
Жду продолжения историй.
29. Ish_2 1117 09.08.17 13:41 Сейчас в теме
Подход хороший. Простые истины через рассказ от первого лица.
Neti; PAVI; +2 – Ответить
34. Kinestetik 25 09.08.17 15:42 Сейчас в теме
Отличная статья, всё по теме
37. Green2 29 10.08.17 07:07 Сейчас в теме
Вы немного уклонились от еще одной проблемы. Скажем так, это даже нравственная заповедь, профессионал должен быть достоин доверия.

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

Надо держать слово в отношении сроков или не давать обещаний.

Если человек даёт какое-то обещание или клянётся сделать что-то, он должен его выполнить. Если он говорит, что сделает что-то, он должен сделать это. Если он говорит, что не станет делать чего-то, он не должен этого делать.

Уважение к человеку в значительной степени зависит от того, держит ли он данное им слово. Родители, например, были бы поражены тем, как сильно они падают в глазах детей, когда не держат своих обещаний.

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

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

Человек, который не держит слова, может вскоре запутаться в сетях различных гарантий и ограничений и даже лишиться нормальных взаимоотношений с окружающими. Нет более надёжного способа отдалиться от других людей, чем нарушение данных ранее обещаний.
YanTsys; PAVI; TreeDogNight; Neti; +4 – Ответить
44. Vovan1975 13 10.08.17 11:05 Сейчас в теме
Срок по задача может быть точно определен только после того как задача решена.
Поэтому все эти оценки сроков - полная туфта. О чем не нужно стесняться говорить, в том числе клиенту.
Все, что можно тут предложить - назначать дату, в которую сходитесь и обсуждаете на какой все стадии и как близко к финалу.
unknown181538; TreeDogNight; 1c-intelligence; +3 – Ответить
46. 1c-intelligence 13240 10.08.17 11:15 Сейчас в теме
(44) еще лучше - назначать не дату, а датЫ, или периодичность.
И обсуждать не только стадии и близость к финалу, но и результаты с прошлой встречи, и как можно ускориться, и пересматривать список оставшихся задач.
60. SunShinne 633 10.08.17 12:24 Сейчас в теме
Просто. Честно. Интересно. Полезно. Автору спасибо, ждём еще статей!
70. alex_sh2008 5 11.08.17 09:12 Сейчас в теме
Есть, но это только в личном общение узнается, не через интернет или почту, а реальное общение.
100. Neti 2647 11.08.17 12:40 Сейчас в теме
Коллеги, если попаду, тоже буду выступать на конференции Infostart Event :)
Если хочется послушать про развитие нетехничеких навыков у разработчиков, то можно проголосовать за мой доклад :)
http://event.infostart.ru/2017/agenda/#item643159
126. Yashazz 4931 13.08.17 11:38 Сейчас в теме
Ребятушки, до тех пор, пока ваш профессионализм будет оценивать тупорылый истеричный главбух или авторитарный самодовольный шеф, или пафосный продажник, вы можете пеной изойти, пытаясь что-то объяснить. Профессионализм в нашем деле - это отнюдь не умение грамотно решить задачу, написать код, внедрить блок, упростить процесс. Нет. Главное - это вежливо улыбаться, когда на тебя льют помои, и стараться сделать так, чтобы это не сильно сказывалось на зарплате. Остальное вторично.
127. boln 1044 13.08.17 14:55 Сейчас в теме
(126)
Главное - это вежливо улыбаться
Не, и тут может докопаться: "Чего лыбу тянешь? Весело? Так щас плакать будешь" :)
147. tailer2 14.08.17 16:07 Сейчас в теме
(126) улыбаться не обязательно

надо иметь глубокую внутреннюю уверенность, что если эта скотина сейчас не заткнется, то сегодня вечером ляжет спать и не проснется уже никогда
152. Neti 2647 17.08.17 16:40 Сейчас в теме
Опубликовали новую историю :)
https://infostart.ru/public/663091/
155. webester 26 01.02.22 11:31 Сейчас в теме
Однажды мне задали вопрос, а я на него ответил. Потом мне задали уточняющий вопрос и я снова на него ответил. Человек пошел своей дорогой а я пошел писать статью на ИС.
Для отправки сообщения требуется регистрация/авторизация