Важно!!! Марафончик 365AX2
Провожу индивидуальные беседы о вашей работе. Бесплатно. Сеанс предположительно 1 час.
Разговор о вашей работе, не столько в плане технических вопросов (хотя это тоже допускается), а больше о:
- рынке
- заработке
- отношении к работе в целом
- возможностях увеличения дохода
- всяком разном, что вас волнует
Зачем это вам:
- попытка найти решение проблемы
- узнать что-то новое и полезное
- получить мнение со стороны
- расширить границы мышления
- найти новые возможности заработка и увеличить доход
Зачем это мне:
- интересна тема такого рода «коучинга» - есть мнение, что могу быть полезен в этом плане, а особенно применительно именно к миру «аксапты», т.к. сам консультант и программист
- новые знакомства и информация
- новые темы для размышления, расширение границ
Разговор предполагается преимущественно о вас, поэтому от вас нужен сначала запрос в какой-либо формулировке, для задания основной темы беседы. Например:
- Работаю программистом. Завис на 200 тыс., хочу 400, 500, 700…
- Работаю консультантом, работы завал, всё всем должен, много работы вообще не связано с Аксаптой, не могу отказать, зп не повышают – можно ли это как-то «мягко» разрулить?
- Работаю программистом, нет четких ТЗ – как организовать работу и свести к минимуму бесполезную трату времени на общение с разными людьми?
- Работаю без удовольствия – как найти мотивацию.
- Надоело каждый день ездить в офис.
- Начальство слишком глупое – мне это не нравится.
- Начальство слишком умное – мне это не нравится.
- Как сменить работу в штате на фриланс?
- …
Поговорим, разберем именно ваши ситуации, попробуем найти решения.
Если интересно, то план такой:
1. От вас письмо на axtalkget@gmail.com с формулировкой своего запроса и предпочтительными датами и временем беседы (если считаете нужным).
2. Отвечаю, договариваемся о времени и способе связи (удобнее удаленно).
Провожу индивидуальные беседы о вашей работе. Бесплатно. Сеанс предположительно 1 час.
Разговор о вашей работе, не столько в плане технических вопросов (хотя это тоже допускается), а больше о:
- рынке
- заработке
- отношении к работе в целом
- возможностях увеличения дохода
- всяком разном, что вас волнует
Зачем это вам:
- попытка найти решение проблемы
- узнать что-то новое и полезное
- получить мнение со стороны
- расширить границы мышления
- найти новые возможности заработка и увеличить доход
Зачем это мне:
- интересна тема такого рода «коучинга» - есть мнение, что могу быть полезен в этом плане, а особенно применительно именно к миру «аксапты», т.к. сам консультант и программист
- новые знакомства и информация
- новые темы для размышления, расширение границ
Разговор предполагается преимущественно о вас, поэтому от вас нужен сначала запрос в какой-либо формулировке, для задания основной темы беседы. Например:
- Работаю программистом. Завис на 200 тыс., хочу 400, 500, 700…
- Работаю консультантом, работы завал, всё всем должен, много работы вообще не связано с Аксаптой, не могу отказать, зп не повышают – можно ли это как-то «мягко» разрулить?
- Работаю программистом, нет четких ТЗ – как организовать работу и свести к минимуму бесполезную трату времени на общение с разными людьми?
- Работаю без удовольствия – как найти мотивацию.
- Надоело каждый день ездить в офис.
- Начальство слишком глупое – мне это не нравится.
- Начальство слишком умное – мне это не нравится.
- Как сменить работу в штате на фриланс?
- …
Поговорим, разберем именно ваши ситуации, попробуем найти решения.
Если интересно, то план такой:
1. От вас письмо на axtalkget@gmail.com с формулировкой своего запроса и предпочтительными датами и временем беседы (если считаете нужным).
2. Отвечаю, договариваемся о времени и способе связи (удобнее удаленно).
Выгодружба
Запись от axtalk размещена 23.05.2021 в 23:00
Наблюдаю и разбираю множество конфликтов консультантов с программистами, когда они в паре работают над задачей.
Разные ситуации. Не совпадают представления и ожидания от обязанностей и работы друг друга. Это подкрепляется страхами и давлением от руководства. Кто-то ошибается, принимает неверные решения и не хочет признавать свои ошибки перед другими или, что ещё хуже, перед собой. Бывает, что не хватает опыта, каждому в своей мере. Часто утопические масштабные задачи оценены исходя из того, что консультант и программист знают функционал и архитектуру наизусть, а они оба видят это впервые.
А процесс обычно построен упрощённо так: консультант описывает, программист делает, консультант тестирует.
Далее начинается перекидывание недоописанных и недоисследованных недорешений с невнятными формулировками от консультанта программисту. Иногда откровенно сырые бизнес требования просто записываются консультантом и передаются без обработки программисту. Программист в условиях информационной недостаточности и ограниченной оценки делает то, что описано, чтобы это хоть как-то было похоже, без уточнения деталей, на которые нет времени. Иногда пытается что-то раскопать, но, чувствуя негативный блок от консультанта, в итоге передает что-то такое же непонятное согласно описанию на тестирование. Консультант начинает проверять что-то там отдаленное от описания и естественно сразу обнаруживает, что что-то не работает или вообще не сделано (часто оно и не было описано).
От этого добавляется негатива, задача идет на доработку, но информации для программиста не прибавляется.
Программист зажат между оценкой, давлением от консультанта и недостатком информации. Чтобы программисту грамотно сформулировать вопрос относительно задачи, надо изучить много кода, а это время, которого нет. Попытки отсылки консультанта на уточнения требований или работы существующего функционала также встречаются консультантом в штыки. Он также зажат оценкой, сроками, негативом от бизнеса, давлением руководителя и недостатком информации, необходимой для выполнения своей роли.
В лучшем случае программист и консультант все-таки договорятся, поймут и сформулируют те вопросы, ответы на которые необходимо получить для выполнения задачи, когда сроки выполнения уже неоднократно сдвинуты, а часы на разработку превышены в 3 раза. К этому моменту наконец-то стало понятно, что и как надо сделать. Но каждый уже получил свой набор минусов в кошелек и репутацию.
Это в лучшем случае. В худшем это дальнейшие разборки, обострение, смена исполнителей (одного или сразу двух) и ещё больше минусов для каждого.
Для наблюдающих за этим процессом сверху, для тех, кто создал или не предотвратил умышленно или случайно такую ситуацию, виноваты будут оба. Кто-то в большей, а кто-то в меньшей степени в зависимости от политической ситуации.
Словом, засада со всех сторон. Никому не выгодное противостояние консультанта и программиста. Не имеет значения, кто виноват больше.
Что вы делите? Что и кому доказываете? Какая цель?
Вместе сообща разверните ситуацию в свою пользу. Получите информацию каждый на своем уровне, сложите этот пазл и выработайте правильную стратегию в своих интересах. Никто не знает всех особенностей лучше вас двоих - пользуйтесь этим.
Если консультанту заранее известен программист, то имеет смысл при осознании задачи и описании решения согласовать его с программистом. Вместе посмотреть, разобрать, оценить, а главное двоим одинаково понять суть планируемой разработки. Когда вам двоим всё понятно, можно легко крутить комбинации для вашей совместной выгоды. Там уже не так важно, что в описании будет - чем сложнее и запутанней, тем лучше для вас. На этом этапе уже можно увеличить бюджет на анализ и описание.
Большую мутную задачу делите на части, выполняйте и тестируйте их отдельно, показывая промежуточные результаты и то, что процесс движется. При видимом движении запросто будут согласовываться новые оценки, сроки и расширение бюджета.
Если программист назначается уже после передачи описания в разработку, то в первую очередь свяжитесь и обсудите. Обозначьте совместно неясные моменты, кто что должен прояснить со своей стороны. Честно признайтесь себе и друг-другу, какие моменты недоработаны со стороны консультанта. Продумайте заранее, как будет проще согласованными действиями и едиными показаниями расширить бюджет на разработку и тестирование.
Обозначайте прямо и без стеснений затраты на анализ процессов, существующего функционала и архитектуры. Это необходимый минимум для построения правильного решения. Будьте единогласны в этом.
Консультант вправе просить себе в помощь программиста, для уточнения функционала по коду. Программист вправе просить помощи консультанта для понимания отражения процесса в системе или создания тестовых примеров для отладки. В вашем взаимодействии это происходит по инициативе помогающей стороны. Даже просить никого не надо.
Подсказывайте друг-другу какие-то особенности, которые помогут каждому быстрее и правильнее выполнить свою роль. Вы в одной лодке. Надо грести одновременно, чтобы двигаться по кратчайшей траектории. Но не забывайте зачем и почему вы поступаете именно так.
Важны три момента:
1. Вы так нежно дружите не потому, что так правильно, не ради глобальных целей проекта, не для радости руководства, не для экономии бюджета, не для процветания компании и пр. Это все и так достигается автоматически. Вы действуете исключительно в своих общих интересах. У вас взаимовыгодная дружба. Вы не просто не засаживаете друг друга и не считаете чужой доход, а даже наоборот проявляете инициативу по дополнительным бонусам и поощрениям своего выгодруга.
2. Ваш сговор — это не обман. Благодаря ему вы вывезли эту мутную задачу, вопреки условиям, в которые были поставлены и бездействию руководителей. Во что это могло превратиться описано в начале этого поста. Благодаря вашим совместным действиям все пошло по благоприятному сценарию. Все довольны, включая руководство. И если уж они этого не понимают, то выпишите себе премию сами.
3. Когда только один понимает и принимает то, что тут описано, так не работает. Важны оба двое. Поэтому прямо сейчас поделитесь ссылкой на Выгодружбу со своим сегодняшним выгодругом, чтобы не тратить время на лишние объяснения.
Разные ситуации. Не совпадают представления и ожидания от обязанностей и работы друг друга. Это подкрепляется страхами и давлением от руководства. Кто-то ошибается, принимает неверные решения и не хочет признавать свои ошибки перед другими или, что ещё хуже, перед собой. Бывает, что не хватает опыта, каждому в своей мере. Часто утопические масштабные задачи оценены исходя из того, что консультант и программист знают функционал и архитектуру наизусть, а они оба видят это впервые.
А процесс обычно построен упрощённо так: консультант описывает, программист делает, консультант тестирует.
Далее начинается перекидывание недоописанных и недоисследованных недорешений с невнятными формулировками от консультанта программисту. Иногда откровенно сырые бизнес требования просто записываются консультантом и передаются без обработки программисту. Программист в условиях информационной недостаточности и ограниченной оценки делает то, что описано, чтобы это хоть как-то было похоже, без уточнения деталей, на которые нет времени. Иногда пытается что-то раскопать, но, чувствуя негативный блок от консультанта, в итоге передает что-то такое же непонятное согласно описанию на тестирование. Консультант начинает проверять что-то там отдаленное от описания и естественно сразу обнаруживает, что что-то не работает или вообще не сделано (часто оно и не было описано).
От этого добавляется негатива, задача идет на доработку, но информации для программиста не прибавляется.
Программист зажат между оценкой, давлением от консультанта и недостатком информации. Чтобы программисту грамотно сформулировать вопрос относительно задачи, надо изучить много кода, а это время, которого нет. Попытки отсылки консультанта на уточнения требований или работы существующего функционала также встречаются консультантом в штыки. Он также зажат оценкой, сроками, негативом от бизнеса, давлением руководителя и недостатком информации, необходимой для выполнения своей роли.
В лучшем случае программист и консультант все-таки договорятся, поймут и сформулируют те вопросы, ответы на которые необходимо получить для выполнения задачи, когда сроки выполнения уже неоднократно сдвинуты, а часы на разработку превышены в 3 раза. К этому моменту наконец-то стало понятно, что и как надо сделать. Но каждый уже получил свой набор минусов в кошелек и репутацию.
Это в лучшем случае. В худшем это дальнейшие разборки, обострение, смена исполнителей (одного или сразу двух) и ещё больше минусов для каждого.
Для наблюдающих за этим процессом сверху, для тех, кто создал или не предотвратил умышленно или случайно такую ситуацию, виноваты будут оба. Кто-то в большей, а кто-то в меньшей степени в зависимости от политической ситуации.
Словом, засада со всех сторон. Никому не выгодное противостояние консультанта и программиста. Не имеет значения, кто виноват больше.
Что вы делите? Что и кому доказываете? Какая цель?
Вместе сообща разверните ситуацию в свою пользу. Получите информацию каждый на своем уровне, сложите этот пазл и выработайте правильную стратегию в своих интересах. Никто не знает всех особенностей лучше вас двоих - пользуйтесь этим.
Если консультанту заранее известен программист, то имеет смысл при осознании задачи и описании решения согласовать его с программистом. Вместе посмотреть, разобрать, оценить, а главное двоим одинаково понять суть планируемой разработки. Когда вам двоим всё понятно, можно легко крутить комбинации для вашей совместной выгоды. Там уже не так важно, что в описании будет - чем сложнее и запутанней, тем лучше для вас. На этом этапе уже можно увеличить бюджет на анализ и описание.
Большую мутную задачу делите на части, выполняйте и тестируйте их отдельно, показывая промежуточные результаты и то, что процесс движется. При видимом движении запросто будут согласовываться новые оценки, сроки и расширение бюджета.
Если программист назначается уже после передачи описания в разработку, то в первую очередь свяжитесь и обсудите. Обозначьте совместно неясные моменты, кто что должен прояснить со своей стороны. Честно признайтесь себе и друг-другу, какие моменты недоработаны со стороны консультанта. Продумайте заранее, как будет проще согласованными действиями и едиными показаниями расширить бюджет на разработку и тестирование.
Обозначайте прямо и без стеснений затраты на анализ процессов, существующего функционала и архитектуры. Это необходимый минимум для построения правильного решения. Будьте единогласны в этом.
Консультант вправе просить себе в помощь программиста, для уточнения функционала по коду. Программист вправе просить помощи консультанта для понимания отражения процесса в системе или создания тестовых примеров для отладки. В вашем взаимодействии это происходит по инициативе помогающей стороны. Даже просить никого не надо.
Подсказывайте друг-другу какие-то особенности, которые помогут каждому быстрее и правильнее выполнить свою роль. Вы в одной лодке. Надо грести одновременно, чтобы двигаться по кратчайшей траектории. Но не забывайте зачем и почему вы поступаете именно так.
Важны три момента:
1. Вы так нежно дружите не потому, что так правильно, не ради глобальных целей проекта, не для радости руководства, не для экономии бюджета, не для процветания компании и пр. Это все и так достигается автоматически. Вы действуете исключительно в своих общих интересах. У вас взаимовыгодная дружба. Вы не просто не засаживаете друг друга и не считаете чужой доход, а даже наоборот проявляете инициативу по дополнительным бонусам и поощрениям своего выгодруга.
2. Ваш сговор — это не обман. Благодаря ему вы вывезли эту мутную задачу, вопреки условиям, в которые были поставлены и бездействию руководителей. Во что это могло превратиться описано в начале этого поста. Благодаря вашим совместным действиям все пошло по благоприятному сценарию. Все довольны, включая руководство. И если уж они этого не понимают, то выпишите себе премию сами.
3. Когда только один понимает и принимает то, что тут описано, так не работает. Важны оба двое. Поэтому прямо сейчас поделитесь ссылкой на Выгодружбу со своим сегодняшним выгодругом, чтобы не тратить время на лишние объяснения.
Всего комментариев 0