В данной статье есть и про то и про другое. Если смотреть не на одного человека, а на команду в целом, то важно, чтобы участники старались и в том и в другом аспекте развиваться. Но я тут снова повторяю ту же мысль, о которой уже написал в статье )
Разве что "ненасильственное общение" как раз не предполагает навязывания, ну или там осуждения за то, что другой человек не использует ненасильственное общение ))))))) Об этом обычно говорят, но легко забыть.
Я как-то писал пет-проект по перт диаграммам. Вот как-то так выглядело:
Хотел там и минимальную-максимальную оценки сделать, чтобы можно было рассчитывать критический путь, оптимистичный и пессимистичный гант и всё такое прочее.
Но потом как-то не увидел перспективы развивать, для себя использовал и забил в итоге.
Наверное не хватило ресёрча, чтобы понять, кому это было бы настолько нужно, чтобы они за такой функционал платили.
Реально можно хоть просто на бумажке рисовать и раскрашивать разными цветами и вся перт диаграмма.
1. Так с вашей точки зрения можно сказать, что и собеседование и составление резюме, и вообще — переписка с потенциальными работодателями в интернете — бессмысленная трата времени. ну а изучение дома новых технологий, или других знаний, умений, навыков, не требующихся прямо сейчас для работы — тем более.
Или есть какая-то разница?
2. Ок, как по вашему работодатель должен «правильно» определять, что человек не только «может» выполнить определённую работу, но и «готов это реально на практике делать». Предложите метод, которым можно отсеить тех, кто точно или потенциально не может. Какойто такой, который позволит с большой вероятностью сделать это, причём ДО испытательного срока.
Предложите «ваш правильный вариант». Который вы бы сами применили, например в своём бизнесе, в который вложили свои честно заработанные несколько миллионов, и не хотите, чтобы они «безрезультатно ушли в песок».
И опять же, если вот лично у вас нет такой потребности и острой необходимости. То чего переживать. Кто-то один требует какую-то фигню, но рядом стоит очередь из тех, кто предлагает более интересные проекты за бОльшие деньги. Где тут место для страданий и переживаний. Если бы действиельно было бы так. То ну это требование, которое вам не нравится, вы бы забыли через пол часа и компанию, которая это требовала, а не бегали бы по всему интернету расказывая «как там кто-то неправ, и как я прав». Вам бы и так было хорошо в каком-то другом проекте, и не до беготни по интернетам было бы.
Ну мы все свободные люди. И наниматели и соискатели. Каждый делает что хочет, каждый реагирует на действия другого как хочет.
Например, у одних есть право не делать тестовое, у других не нанимать тех, кто не делает тестовое и т.д.
Это открытый мир и свободный рынок.
P.S. Если на собеседование приходит человек, который «не хочет здесь работать, а хочет чтобы его убеждали», то наверное это психологическая игра. Несколько токсичная. Чуть-чуть. По ней можно сделать некоторые выводы. И например начать копать, а нет ли у человека ещё каких-то токсичных загонов.
Если человек не хочет сделать небольшое тестовое, то где гарантия, что он потом захочет выполнять задачи в процессе работы? А то сначала «я тимлид, поэтому у меня нет необходимости продать себя поэтому тестовое делать не буду», а потом «я тимлид, мне не нужно никому ничего доказывать, поэтому делать ничего не буду, отчитываться перед начальством о ходе работы и текущем состоянии в проекте не буду, показывать результаты своей работы не буду, и вобще делать ничего не буду, а зарплату мне платите потому, что я такой классный, а если вы усомнитесь в моей классности, то я уйду к другим не работать».
Имхо, угроза того, что человек будет относиться к работе таким образом — достаточно сущестенный риск. Хотя бы с точки зрения финансовых и временных затрат: habr.com/ru/company/redmadrobot/blog/495108
Вы не хотите делать лишнее, а работодатель не хочет нести риски найма человпка который будет «агрессивно бездельничать» за его счёт.
Соответствено, опять же, каждый из вас пользуется своим правом делать то, что он хочет и не делать того, что он не хочет. Каждый поступает свободно исходя из своих личных целей.
Несвобода начинается там, где один хочет заставить другого, и стоит с автоматом угрожая расстрелом, говоря: «делай тестовое иначе расстреляю», или «не требуй от меня тестовое, иначе расстреляю».
Поиск работы — это продажа. Продажа требует сил и времени.
В крупных компаниях продажами занимаются отдельно нанятые люди.
При продаже себя, например на рынке труда или во фрилансе — ты тратишь своё же время на это.
Только при поиске работы ты продаёшь себя один раз (пока не захочешь сменить работу), а во фрилансе — на каждом новом заказе/заказчике. И во фрилансе время на продажу и вообще взаимодействие с заказчиком может быть больше, чем собственно на выполнение работы.
Поэтому, лично для меня, поиск работы по найму (в отличие от фриланса) это как «закрыть одну крупную сделку вместо тысячи мелких».
Это так же очевидно, как, например, очевидно, что какой-нибудь «бизнес по созданию сайтов» сильно не то же самое, что «работа по программированию сайтов».
Ну вот как я написал в статье — так и решаем )
Если говорить за организационные моменты, то это тема интересная. Но в подробностях я её раскрыть не смогу, так как для этого нужно описать чем, как и почему занимается наша компания, как она устроена организационно внутри, и почему именно так. Как это всё работает. И уже потом раскрывать эту тему.
Пока что такой возможности нет. Может быть в другой раз, если по NDA разрешат на какой-нибудь конференции поделиться )
А вообще, вы же можете написать свою заметку с той информацией, которую вы знаете, но которой нет в данной статье, и которая по-вашему представляет ценность для читателей. Для тех людей, которые ещё не знают того, что знаете и на практике применили вы. Я думаю это было бы весьма полезно и интересно.
1. нельзя в сыром виде отдавать хотелки разработчикам
2. нужно понять какую реальную проблему мы решаем
3. нужно смотреть на всю картину из всех этих проблем, и потом уже на основании этого выделять проекты, истории, декомпозировать на технические задачи
4. есть много одинаковых, повторяющихся в НАШЕЙ работе ситуаций, и я описал по самым основным и повторяющимся, что можно с этим сделать. Нарпимер:
4.1. если функционал есть — рассказать человеку как ПРАВИЛЬНО пользоваться
4.2. если много повторяющихся хотелок — обобщить и делать единообразно
4.3. если есть конфликтующие требования — то нужно их пытатсья разрулить, и вот такие варианты есть как их можно разруливать (ясно, что не стоит просто в лоб пытаться реализовать оба конфликтующих требования, иначе при выкате на прод всё сломается нафиг — а такое может быть если один менеджер дал напрямую одному разработчику одну задачу, а другой менеджер дал другому разработчику другую задачу)
Возможно, в вашей практике, и в вашей работе таких проблем не возникает или вы уже знаете как их решать и успешно решаете более сложные проблемы.
Но я вижу в реальной жизни много людей, которые не делают даже описанного в статье, и видел в своей жизни много компаний, которые даже такие простые проблемы не могли решить или даже не пытались. Это существует в реальном мире.
И я рад что у вас этого нет. Но это не повод не делиться опытом.
У нас например в начале проекта в котором я работаю эти проблемы все были и ни одна из них не была решена. Но постепенно мы их все плюс-минус зарешали, хотя иногда до сих пор бывает что кто-то с квадратными глазами вбегает к разработчику и говорит что нужно срочно сделать новую табличку из которой будет что-то как-то куда-то считаться. И разработчик начинает делать.
И приходится потом бегать, рассказывать что у нас уже есть готовая система, которая уже считает и отдаёт то, что нужно, и выдёргивать из рук разработчика наполовину сделанную задачу )))) Но с каждым разом таких единичных случаев всё меньше и меньше.
Ещё раз повторю, я очень рад, что у вас такого нет и всё хорошо.
Тут не описано про классификацию задач, потому что у нас по сути нет такой классификаци. Мы же не расатриваем здесь баги.
на всё остальное кроме багов у нас есть два вида задач для разработчиков — стори и дев. дев — это когда никакой функционал не меняет внешнюю логику работы, а только что-то внутренне техническое.
А всё что на тему функционала — кусок большого проекта, или одна отдельная независимая фича — это всё равно стори.
Если есть много стори на разные компоненты системы, или даже на один — то под это есть агрегирующая их задача другого типа. Котрая например «внедрить вот такую-то новую большую штуку». И там внутри неё с десяток разных производственных задач.
И эти стори и дев уже раздаются разработчикам.
Возможно у вас есть много типов задач для разработчиков и вам это нужно. У нас вот такого варианта вполне хватает.
1. хотелки
2. описанные задачи готовые к разработке
3. продуманные планы — когда какие задачи делаем, спринты, кварталы или какие-то приоритеты и т.д. — смотря какая система управления проектами/командами используется в конкретном случае
4. реализация задач (программирование и всё что связано с разработкой, включая архитектуру и т.п.)
5. тестирование
6. релиз — задачи доставлены и работают
7. обратная связь по результатам использования
Тут про пункты 1 и 2. Про другие пункты есть другие статьи/материалы от других авторов.
В данном случае это как раз по мотивам практики работы, и статья не предполагает охватить всю тему управления проектами, требованиями, командами, качеством реализации требований и т.д.
А охватывает только часть между «хотелками» и «реализацией», которая именно про сами требования. Возможно название ввело кого-то в заблуждение и тут ожидали увидеть например как меняются требования в процессе разработки и что с этим делать и.т.д. Но тут этого нет.
Если тут кто-то хотел увидеть, как и на какое время вперёд задачи можно планировать, распределять, приоритизровать, как их декомпозировать — то тут этого тоже нет (мне кажется, что тема статьи сильно о другом). Так же тут нет работы с результатами реализации требований.
Возможно стоит вынести в предисловие список того, чего эта статья не пытается раскрыть, чтобы не давать ложных ожиданий. Так как тема узкая и конкретная. К нам влетают хотелки/требования/пожелания/проблемы и т.д. а мы с ними работаем и на выходе получаем то, что пригодно для разработки. Всё.
Мне кажется, что нельзя, неправильно и вообще нет смысла брать и писать статью «сразу обо всём», пересказывая всё что существует в мире на эту тему.
В данной статье есть и про то и про другое. Если смотреть не на одного человека, а на команду в целом, то важно, чтобы участники старались и в том и в другом аспекте развиваться. Но я тут снова повторяю ту же мысль, о которой уже написал в статье )
хороший поинт, да
Я даже сервис по подбору психотерапвтов порекомендовать могу, но боюсь это всё будет считаться рекламой.
Согласен )
Разве что "ненасильственное общение" как раз не предполагает навязывания, ну или там осуждения за то, что другой человек не использует ненасильственное общение ))))))) Об этом обычно говорят, но легко забыть.
Хотел там и минимальную-максимальную оценки сделать, чтобы можно было рассчитывать критический путь, оптимистичный и пессимистичный гант и всё такое прочее.
Но потом как-то не увидел перспективы развивать, для себя использовал и забил в итоге.
Наверное не хватило ресёрча, чтобы понять, кому это было бы настолько нужно, чтобы они за такой функционал платили.
Реально можно хоть просто на бумажке рисовать и раскрашивать разными цветами и вся перт диаграмма.
2. Ок, ушли от ответа:
— вот так неправильно
— а как правильно?
— …
Или есть какая-то разница?
2. Ок, как по вашему работодатель должен «правильно» определять, что человек не только «может» выполнить определённую работу, но и «готов это реально на практике делать». Предложите метод, которым можно отсеить тех, кто точно или потенциально не может. Какойто такой, который позволит с большой вероятностью сделать это, причём ДО испытательного срока.
Предложите «ваш правильный вариант». Который вы бы сами применили, например в своём бизнесе, в который вложили свои честно заработанные несколько миллионов, и не хотите, чтобы они «безрезультатно ушли в песок».
Или нет?
Например, у одних есть право не делать тестовое, у других не нанимать тех, кто не делает тестовое и т.д.
Это открытый мир и свободный рынок.
P.S. Если на собеседование приходит человек, который «не хочет здесь работать, а хочет чтобы его убеждали», то наверное это психологическая игра. Несколько токсичная. Чуть-чуть. По ней можно сделать некоторые выводы. И например начать копать, а нет ли у человека ещё каких-то токсичных загонов.
Если человек не хочет сделать небольшое тестовое, то где гарантия, что он потом захочет выполнять задачи в процессе работы? А то сначала «я тимлид, поэтому у меня нет необходимости продать себя поэтому тестовое делать не буду», а потом «я тимлид, мне не нужно никому ничего доказывать, поэтому делать ничего не буду, отчитываться перед начальством о ходе работы и текущем состоянии в проекте не буду, показывать результаты своей работы не буду, и вобще делать ничего не буду, а зарплату мне платите потому, что я такой классный, а если вы усомнитесь в моей классности, то я уйду к другим не работать».
Имхо, угроза того, что человек будет относиться к работе таким образом — достаточно сущестенный риск. Хотя бы с точки зрения финансовых и временных затрат: habr.com/ru/company/redmadrobot/blog/495108
Вы не хотите делать лишнее, а работодатель не хочет нести риски найма человпка который будет «агрессивно бездельничать» за его счёт.
Соответствено, опять же, каждый из вас пользуется своим правом делать то, что он хочет и не делать того, что он не хочет. Каждый поступает свободно исходя из своих личных целей.
Несвобода начинается там, где один хочет заставить другого, и стоит с автоматом угрожая расстрелом, говоря: «делай тестовое иначе расстреляю», или «не требуй от меня тестовое, иначе расстреляю».
В крупных компаниях продажами занимаются отдельно нанятые люди.
При продаже себя, например на рынке труда или во фрилансе — ты тратишь своё же время на это.
Только при поиске работы ты продаёшь себя один раз (пока не захочешь сменить работу), а во фрилансе — на каждом новом заказе/заказчике. И во фрилансе время на продажу и вообще взаимодействие с заказчиком может быть больше, чем собственно на выполнение работы.
Поэтому, лично для меня, поиск работы по найму (в отличие от фриланса) это как «закрыть одну крупную сделку вместо тысячи мелких».
Это так же очевидно, как, например, очевидно, что какой-нибудь «бизнес по созданию сайтов» сильно не то же самое, что «работа по программированию сайтов».
Если говорить за организационные моменты, то это тема интересная. Но в подробностях я её раскрыть не смогу, так как для этого нужно описать чем, как и почему занимается наша компания, как она устроена организационно внутри, и почему именно так. Как это всё работает. И уже потом раскрывать эту тему.
Пока что такой возможности нет. Может быть в другой раз, если по NDA разрешат на какой-нибудь конференции поделиться )
1. нельзя в сыром виде отдавать хотелки разработчикам
2. нужно понять какую реальную проблему мы решаем
3. нужно смотреть на всю картину из всех этих проблем, и потом уже на основании этого выделять проекты, истории, декомпозировать на технические задачи
4. есть много одинаковых, повторяющихся в НАШЕЙ работе ситуаций, и я описал по самым основным и повторяющимся, что можно с этим сделать. Нарпимер:
4.1. если функционал есть — рассказать человеку как ПРАВИЛЬНО пользоваться
4.2. если много повторяющихся хотелок — обобщить и делать единообразно
4.3. если есть конфликтующие требования — то нужно их пытатсья разрулить, и вот такие варианты есть как их можно разруливать (ясно, что не стоит просто в лоб пытаться реализовать оба конфликтующих требования, иначе при выкате на прод всё сломается нафиг — а такое может быть если один менеджер дал напрямую одному разработчику одну задачу, а другой менеджер дал другому разработчику другую задачу)
Возможно, в вашей практике, и в вашей работе таких проблем не возникает или вы уже знаете как их решать и успешно решаете более сложные проблемы.
Но я вижу в реальной жизни много людей, которые не делают даже описанного в статье, и видел в своей жизни много компаний, которые даже такие простые проблемы не могли решить или даже не пытались. Это существует в реальном мире.
И я рад что у вас этого нет. Но это не повод не делиться опытом.
У нас например в начале проекта в котором я работаю эти проблемы все были и ни одна из них не была решена. Но постепенно мы их все плюс-минус зарешали, хотя иногда до сих пор бывает что кто-то с квадратными глазами вбегает к разработчику и говорит что нужно срочно сделать новую табличку из которой будет что-то как-то куда-то считаться. И разработчик начинает делать.
И приходится потом бегать, рассказывать что у нас уже есть готовая система, которая уже считает и отдаёт то, что нужно, и выдёргивать из рук разработчика наполовину сделанную задачу )))) Но с каждым разом таких единичных случаев всё меньше и меньше.
Ещё раз повторю, я очень рад, что у вас такого нет и всё хорошо.
на всё остальное кроме багов у нас есть два вида задач для разработчиков — стори и дев. дев — это когда никакой функционал не меняет внешнюю логику работы, а только что-то внутренне техническое.
А всё что на тему функционала — кусок большого проекта, или одна отдельная независимая фича — это всё равно стори.
Если есть много стори на разные компоненты системы, или даже на один — то под это есть агрегирующая их задача другого типа. Котрая например «внедрить вот такую-то новую большую штуку». И там внутри неё с десяток разных производственных задач.
И эти стори и дев уже раздаются разработчикам.
Возможно у вас есть много типов задач для разработчиков и вам это нужно. У нас вот такого варианта вполне хватает.
2. описанные задачи готовые к разработке
3. продуманные планы — когда какие задачи делаем, спринты, кварталы или какие-то приоритеты и т.д. — смотря какая система управления проектами/командами используется в конкретном случае
4. реализация задач (программирование и всё что связано с разработкой, включая архитектуру и т.п.)
5. тестирование
6. релиз — задачи доставлены и работают
7. обратная связь по результатам использования
Тут про пункты 1 и 2. Про другие пункты есть другие статьи/материалы от других авторов.
А охватывает только часть между «хотелками» и «реализацией», которая именно про сами требования. Возможно название ввело кого-то в заблуждение и тут ожидали увидеть например как меняются требования в процессе разработки и что с этим делать и.т.д. Но тут этого нет.
Если тут кто-то хотел увидеть, как и на какое время вперёд задачи можно планировать, распределять, приоритизровать, как их декомпозировать — то тут этого тоже нет (мне кажется, что тема статьи сильно о другом). Так же тут нет работы с результатами реализации требований.
Возможно стоит вынести в предисловие список того, чего эта статья не пытается раскрыть, чтобы не давать ложных ожиданий. Так как тема узкая и конкретная. К нам влетают хотелки/требования/пожелания/проблемы и т.д. а мы с ними работаем и на выходе получаем то, что пригодно для разработки. Всё.
Мне кажется, что нельзя, неправильно и вообще нет смысла брать и писать статью «сразу обо всём», пересказывая всё что существует в мире на эту тему.