Решил, недавно, попробовать новую версию скайп'а, нужен был функционал в групповом чате обращаться к конкретным пользователям (в старой версии это криво, через команду). Мучился я с ним 3 дня: постоянные потери контента (не видно текст сообщений) при перетаскивании с одного экрана на другой, много багов со встроенным просмотрщиком изображений, не возможность быстро скинуть не нужных пользователей при групповом звонке и многое другое, в итоге я снова в 2014)
То что я описал, — это не стереотипы, а личные наблюдения в работе. Моя основная работа — это работа с людьми, так как я управленец, и основной вывод, который я делаю по этому, щепетильному, вопросу: с девушками/женщинами чуть тяжелее работать, и также на собеседование с ними нужно потратить чуть больше времени и сил, но если у меня будет возможность взять на работу кандидата, который полностью удовлетворяет запросам организации, то я не посмотрю на его пол. Со всеми людьми, если идет речь о высококвалифицированных специалистах, тяжело работать, к каждому нужно искать подход и т.п.
Не знаю почему на девушку накинулись в комментариях, вполне нормальная статья для первого раза. По теме, трудности в работе с девушками/женщинами (личный опыт):
излишняя эмоциональность, с мужчинами меньше такое бывает;
трудно предъявить за не качественно выполненную работу, после объективных доводов, все может сойтись банально к тому: «это потому что я девушка?!»;
феминизм и подобные -измы: «вы меня угнетаете по сравнению с другими, потому что я женщина, у меня меньше зп, та как я женщина и т.п.»;
за частую девушка больше нуждается в похлопывании по плечу, если ее результаты не замечают, может начать не стабильно работать;
Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как любому может достаться любая задача, то и на планерка должны быть все.
Да, — это по той причине, что задачи пересекаются и могут достаться любому, и чтобы не объяснять по десять раз, если исполнитель поменяется, собираемся, чтобы объяснить один раз.
При работе с электронными системами контроля задач важны следующие навыки:
грамотно и понятно называть задачи;
умение пользоваться поиском и фильтрами;
умение вовремя обновлять статус задачи;
умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.
Я с вами полностью согласен, что нужно пользоваться электронными системами, к этому мы и пришли своим путем.
Оценивать задачу должен исполнитель.
К этому мы тоже пришли, но это правильно, если исполнитель один и не изменим не при каких обстоятельствах.
В статье я писал, что на предприятии используется битрикс, и в ближайших планах: мы будем с ним взаимодействовать. И про scrumban я писал, даже есть ссылка на магазин. Но чесно говоря, нам в it-отделе, он не особо нравится.
1. Пример про четыре часа планирования был приведен из одной команды, в других планирование проходит быстрее. Четыре часа: данная команда работает над сложными техническими решениями и только ведущий разработчик имеет понимание, как решать поставленные задачи. Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все. Подчеркну, что длинная планерка только у одной команды.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.
Основная проблема: отсутствие структурности и системности в работе it-отдела организации.
Возможно, я не раскрыл всю картину, деятельность нашей организации больше чем на половину не it, вот там то все и крутится у руководства. У меня не достаточно опыта, чтобы организовывать все самому.
Agile мы применяем разумно, есть проекты, которые идут по старой доброй каскадной модели, так как мы работаем и с тендерами в том числе, а там нужно иметь четкие сроки завершения того или иного этапа. У всего должна быть мера. Я далеко не из тех, которые пропагандируют agile и только его. И сравнение лошади и машины, — это сравнение того как работали раньше (абы как) с тем, что есть сейчас.
Да, у меня нет сравнения, так как новую систему строил я, а старых данных у меня к сожалению нет. Да и команда/технологии/процессы кардинально поменялись, тут было бы сравнение не в двигателях, а сравнение лошади и машины.
Вы правы, на подготовку уходит много времени, и я это отмечал, как большую проблему в статье. Но нет, большинство времени уходит не на это. Потраченный день на обсуждение и разжевывание задач ничто по сравнению с тем, какие потери могут быть, например: разработчик не правильно понял feature и реализовал её не так, как нужно было клиенту, или, недавно был случай: клиенту не показали, как положено по регламенту модель его аппарата и сразу сделали боевой образец, итог, аппарат стоит пылится, такой клиенту он не нужен (банально не провели демо).
Redmine с плагином backlog's предоставляет некоторую электронную доску задач, но она мне не совсем нравится. Плагин для 1С Битрикса потрогал, но пока дальше в работу не пошло. В ближайшее время планируем внедрять. Посмотрю ту, которую вы посоветовали, спасибо.
Видимо я плохо передал некоторые нюансы. Agile, потому что он позволяет адаптировать разрабатываемый продукт под нужны клиента/руководителя в самые короткие сроки, чем короче итерации, тем быстрее можно перекроить планы, а это нам и было нужно он «фреймворка» ведения проекта. Да, вы правы, для улучшения качества и быстроты нужно внедрять еще множество технических процессов разработки. У нас они внедряются параллельно тому, что описано в этой статье.
Я не в коем случае не говорю, что нужно действовать не честными методами. Но, в том числе и в статье, приведены методы, которые являются честными, но при определенной интерпретации и не должном применении могут быть восприняты сотрудниками, как ложь и ухищрения. Если к работникам, тем более в сложной ситуации, относиться по человечески, то и с их стороны будут некоторые поблажки.
Очень похоже на нашу ситуацию. Думаю такие «похожие» ситуации не редки в нашем мире, у меня много знакомых, которые также, как и в нашей компании выросли вместе со своими проектами, и они привязаны к ним, как к детям, тяжело, иногда не возможно бросить свое, иногда несуразное, детище.
На пункт 1. Все задачи требуют программистов высокого уровня, нанимать дешевых — больше времени потратим на обучение, уже проходили. На пункт 2. Другие расходы идут не от отдела IT, расходы только увеличиваются, повлиять на это нет возможности. На пункт 3. Тоже самое что в пункте 1, уже пробовали, очень много времени уходит у специалистов на разъяснение того, как нужно делать, зашиваются, не успевают кодить.
Из-за неправильного стратегического движения, менеджмент вынужден предпринимать меры, чтобы не терять свои «родные» проекты и людей, на выращивание которых потрачено много сил.
«Меры» — не в коем случае не обман, а то что помогает оставаться единым коллективом в сложной ситуации.
Не совсем с вами согласен. Наши разработчики (в большинстве своем процентов 75) делают свои проекты, за частую так, как им это заблагорассудится (естественно в разумных пределах), то есть они ведут его так как им это интересно, используют технологии, на которых хотят это делать. И говоря свои проекты, я подразумеваю, что разработчик за частую сам вносит предложения по функционалу, и после одобрения и планирования, он реализует свою фичу. Подводя итог, Разработчикам дается большая свобода в реализации проектов, и возможно, частично из за этого есть некоторые просадки в бизнесе, по этому уровень финансов бывает ограничен, и чтобы разработчик не захотел сменить работу на гораздо более оплачиваемую, приходится применять некоторые «тактики» работы с ним.
Все это лишь мой опыт, не в обиду кому-то
Да, — это по той причине, что задачи пересекаются и могут достаться любому, и чтобы не объяснять по десять раз, если исполнитель поменяется, собираемся, чтобы объяснить один раз.
Я с вами полностью согласен, что нужно пользоваться электронными системами, к этому мы и пришли своим путем.
К этому мы тоже пришли, но это правильно, если исполнитель один и не изменим не при каких обстоятельствах.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.
Основная проблема: отсутствие структурности и системности в работе it-отдела организации.
На пункт 2. Другие расходы идут не от отдела IT, расходы только увеличиваются, повлиять на это нет возможности.
На пункт 3. Тоже самое что в пункте 1, уже пробовали, очень много времени уходит у специалистов на разъяснение того, как нужно делать, зашиваются, не успевают кодить.
Из-за неправильного стратегического движения, менеджмент вынужден предпринимать меры, чтобы не терять свои «родные» проекты и людей, на выращивание которых потрачено много сил.
«Меры» — не в коем случае не обман, а то что помогает оставаться единым коллективом в сложной ситуации.
Подводя итог, Разработчикам дается большая свобода в реализации проектов, и возможно, частично из за этого есть некоторые просадки в бизнесе, по этому уровень финансов бывает ограничен, и чтобы разработчик не захотел сменить работу на гораздо более оплачиваемую, приходится применять некоторые «тактики» работы с ним.