В свое время схожим образом автоматизировал через VBA-скрипты, когда множество отделов присылали разнородные данные, которые требовалось нормализовать.
Самое сложное из практики не автоматизировать, а не повредить данные. Как с этим боролись? :)
Доброго дня! Прочитал с интересом, есть несколько интересных мыслей.
Дам некоторые комментарии со своей стороны, возможно, что будет и вам полезно.
Аналитик часто неосознанно, а иногда и осознанно, может выполнять функции проектного менеджера (руководителя проекта).
Это работает только в одном случае, если аналитик и РП - это одно лицо.
РП - это про общение с заказчиком, требуется навык переговоров. Его основной инструмент - язык. Аналитик - это про технику, требуется хорошие понимание того, как можно слова заказчика перевести в технические термины. Его основной инструмент - технические средства.
И вы далее сами это подтверждаете.
Но все же, глобально, аналитик и руководитель проекта несут общую ответственность за финальный продукт и могут одновременно управлять задачами и бэклогом.
Таким образом вы размываете зоны ответственности и увеличиваете шанс что-то забыть. Более того, контактным лицом становится не РП, а аналитик - это большая проблема.
Аналитик способен исполнять обязанности проектного менеджера исключительно при наличии желания развиваться в данном направлении ...
А чем в этом случае будет заниматься проектный менеджер? Если один человек тянет функционал вместо двух - это приведет к выгоранию сотрудника. По итогу не останется ни аналитика, ни менеджера.
При этом далее описываемые преимущества не имеют реальной силы. Специалист всегда будет лучше, чем "фуллстек". Вы получите либо "недоменеджера", либо "недоаналитика".
Для стартапа - это приемлемо в силу экономии ФОТ. Для иных компаний - нет.
Совмещение ролей руководителя проекта и аналитика подходит для небольших проектов с ограниченным объемом ресурсов и несложными задачами. Для сложных крупномасштабных проектов всё же рекомендуется раздельное исполнение ролей, что позволит минимизировать негативные последствия перегрузки и повысить общую эффективность командной работы.
Если у вас 2 ставки, то не имеет смысла "делегировать", размывая зону отвественности. Если у вас 1 ставка, то не имеет смысла рассуждать о том, что аналитик совмещенный с РП - это отлично.
Вы просто работаете с теми реалиями, которые у вас есть в проекте.
Нередко аналитик становится спасателем хаотичного или трудного проекта.
Здесь хочется уточнить, а как проект стал хаотичным, если в нем есть и аналитик и РП? Кто-то из них явно не на своем месте или имеет низкую квалификацию.
Далее как раз вы об этом и пишите, описывая проблемы, которые возникли. "Пожары" - это ошибка либо аналитика, либо РП, либо обоих сразу.
Ни один из разработчиков не общается с заказчиком, а значит, "сломанный телефон" возник именно на уровне РП / аналитика.
И даже когда аналитик не руководитель проекта, он всегда может реализовать проект, если он: участвует в каждом этапе проекта и используют лучшие практики.
Возможно, что вам стоит побольше пообщаться с командами разработки.
Если аналитик везде будет использовать лучшие практики - проект вообще не запустится. Задача аналитика не лучшие практики собирать, а найти баланс между "правильно" и "работает". При необходимости от него же требуется обосновать выбор заказчику.
Затраты на "правильную архитектуру" будут в 2-3 раза выше в силу того, что потребуется очень много всего "поверх работающего кода". Бизнес не даст на это тратить средства.
Дополнительно бизнес даст DL по сдаче проекта. Как итог "лучшие практики" заменит обычное "работает - не трогай".
В целом ваша статья выглядит так, что "аналитик" - это "серебряная пуля" или что-то очень близкое к этому. Ранее встречал у других авторов аналогичные статьи, где "серебряной пулей" выступал РП, тестировщик и т.п.
Если должность существует - это, вероятно, не просто так. Экономия на РП / аналитике - это экономия на качестве проекта в целом, причем на самом важном этапе, т.е. сборе требований от заказчика.
Мое личное убеждение, что так делать стоит только в крайнем случае. В любом случае спасибо за статью - интересная :)
На стартапе да, схожий расклад. Чем больше человек универсал - тем лучше.
Но опять же, сейчас даже в QA стек такой, что приходится какой-либо профиль выбирать по итогу. А вот руководители, аналитики и тим лиды как раз должны быть "универсалами", чтоб понимать вектор потенциальных сложностей при разработке.
Иначе, как описал автор, будет "аналитик не знает, что такое API".
Добрый день! Спасибо за статью, весьма интересное мнение, особенно для первой статьи :) Пишите, обязательно, еще!
Ниже дал некоторые комментарии как руководитель отдела разработки. В самом низу есть определенные выводы. Пишу то, в чем с вами, как автором, не согласен. Могу быть не прав - везде своя кухня :)
Если хотите, то можем подробно обсудить потом детали - открыт к диалогу, чем смогу - помогу :)
Но часто между ними возникает напряжение: тестировщики находят баги, разработчики видят их как критику. Как это изменить?
В данном случае вы видите, скорее всего, лишь часть картины. Разработчик воспринимает это как критику не потому, что это его ущемляет, а потому, что это "не предусмотрено ТЗ".
Есть задача "собрать автомобиль на 4 человека". Разработчик это делает. Следом приходит тестировщик и садится на автомобиль сверху, составляет баг-репорт "проехал сверху - сдувает".
Разработчик идет к бизнес аналитику и спрашивает "а разве это бизнес-кейс?"
Аналитик идет к заказчику, который отвечает "Да, давайте предусмотрим такой вариант, мы про него совсем забыли".
Дедлайн никто не передвинет.
Т.е. то, что вы воспринимаете как негатив к тестировщику на деле является ошибками технического задания.
Используйте технический язык, но адаптируйте его:
Не начинайте разговор с эмоций ("Это же непрофессионально!").
Объясните, почему баг важен: "Если пользователь не может завершить покупку, это приведет к потере 20% конверсии".
Эмоции в баг репортах вообще недопустимы и не требуются. Каждый выполняет работу так, как может. Иногда кастомизация превращается в "кастылизацию" и с этим ничего не поделаешь. Есть баг - его требуется описать.
Объяснять почему этот баг это важно - все же не задача тестировщика. Это больше к руководителю проекта вопрос :) Вы можете не знать "подкапотья" задумки и поставить высший приоритет вообще не важному багу.
Разработчики ценят, когда тестировщики не просто находят ошибки, но помогают их решать. Например: «Я попробовал найти способ обойти этот баг, но не получилось. Возможно, стоит пересмотреть архитектуру модуля?»
Рекомендую не давать советы по исправлению - это бесит разработчиков :)
У вас недостаточно для этого опыта и в большинстве случаев вы работаете в варианте Grey или Black Box, не понимая особенностей реализации. Либо ваше место не в тестировании :)
Вы можете дать предположение о причинах формата "тронул модуль А - вылетел модуль Б", вот такой комментарий действительно поможет, он устанавливает причинно-следственную связь и дает предположение о том, где может быть источник.
Сфокусируйтесь на общих целях — качественном продукте. Вместо «Вы снова всё испортили» скажите: «Давайте вместе разберемся, как это исправить».
В каждой компании, конечно, своя кухня...
Однако, если тестировщик даст комментарий формата "вы виноваты", то первое, что я сделаю как руководитель отдела - это задумаюсь, нужен ли такой тестировщик, который вместо командной игры перекидывает ответственность :) Попахивает токсичностью очень сильно.
Разработка - это "мы", т.е. нет виноватых вообще. Есть задача, которую требуется решить в нужный срок. Все ошибаются и разработчики не исключение :)
Иначе следом можно сказать, что тестировщик пропустил баг в прод. "Видишь баг? Нет? Он просто еще не стрельнул!" :)
Предлагайте сценарии тестирования:
Если требования нечеткие, создайте примеры использования. Например: "Если пользователь заполнит форму с ошибками, как система должна реагировать?"
Не предлагайте, а готовьте. Одна из важных задач тестировщика подготовить сценарии тестов.
В идеале их лучше иметь на руках до начала разработки, чтоб разработчик на их базе понял в каких местах потребуется валидация данных. По сути большая часть багов - это не валидированные элементы бизнес-логики.
Но опять же, они должны быть согласованы с руководителем проекта. Иначе будет история про "погрыз провод - меня ударило током". Не надо тестировать то к чему не будет доступа у потенциального пользователя.
И не надо мешать тесты производительности, регрессию, ИБ и т.п. с тестами пользователей. Везде свои особенности.
Покажите, что вы понимаете бизнес-задачи:
Откровенно вредный совет. Вы либо их понимаете, либо нет.
Не надо показывать, что вы их понимаете. Иначе наступит момент Х, когда ожидание разойдется с реальностью очень сильно. Все думают, что вы понимаете, а вы "показываете, что понимаете".
С аналитиками, не знакомыми с ИТ, говорите простым языком. Например, вместо «API‑запросы» скажите «запросы между системами».
Опять же, в каждой компании своя кухня. Но аналитик требований без знания ИТ? Это очень серьезная проблема для компании.
С технически подкованными коллегами можно обсуждать детали, но не перегружайте их технической терминологией.
Опять же вредный совет. Его стоит переформулировать так: "Если не уверены в термине - не употребляйте его вообще, иначе запутаете специалиста".
Будьте терпеливы к изменениям:
Аналитики часто пересматривают требования. Вместо раздражения предложите: «Давайте вместе пробежимся и посмотрим, как это повлияет на текущие сценарии».
Смена ТЗ всегда будет вызывать раздражение, без вариантов. К сожалению.
Причина до банального проста - потерянное время, как итог "горящие дедлайны". Утешать никого не требуется - это реалии разработки в РФ :)
Объясняйте технические ограничения через выгоды для пользователя:
Если маркетолог хочет добавить анимацию, но она вызывает лаги, скажите: «Давайте сначала убедимся, что система не тормозит. Тогда анимация будет радовать пользователей, а не раздражать».
Если маркетолог хочет добавить анимацию, то его остановит только требуемый бюджет или сроки :)
Маркетологу нет дела тормозит или нет анимация, его задача сделать так, чтоб продукт вызывал нужные эмоции и как итог активнее продавался.
Сделать, чтоб не тормозило - задача разработчика (в данном случае фронт разработчика).
Задача тестировщика, на мой взгляд, не лезть к маркетологу и заниматься тестированием. Для этого есть линейный руководитель, который, если нужно, донесет нужные мысли горизонтально или вертикально.
Используйте данные для аргументации:
Если маркетолог настаивает на дизайнерском решении, покажите, как оно может повлиять на производительность. Например: «Такой слайдер увеличивает время загрузки на 3 секунды, что снижает вовлеченность на 15%» — конечно же, если тестировщик обладает такими навыками расчета =).
Категорическое нет :)
Если он настаивает - руководитель проекта должен обратиться к тим лиду, тим лид к разработчику, а разработчик должен придумать метод оптимизации анимации.
Ваш вариант - это вместо решения бизнес-задачи за которую платит ваш заказчик - найти причину "почему мы не справились".
Сейчас вы не реализуете задумку, завтра вам не дадут новый проект. Все очень просто :)
Используйте метрики, понятные бизнесу:
Вместо «найдено 50 багов» скажите: «Риск ошибок в платежной системе снижает доверие пользователей. Мы можем сэкономить 1 000 000 рублей, если исправить это до запуска».
Вы уверены, что ваш комментарий не приведет к пересогласованию бюджета и остановке проекта? Вы уверены, что ваша методика оценки совпадает с реальными рисками для бизнеса? Вы уверены, что ...
Не бойтесь говорить о рисках:
Бизнес ценит честность. Скажите: «Если мы не протестируем этот модуль, вероятность сбоя на День Святого Валентина составляет 30%».
Бизнес ценит выполнение взятых на себя обязательств :)
Если вы сказали, что сдадите продукт 01.07, а сдали его 01.12 - это очень плохо. Даже если вы сказали об этом честно 01.06.
На этом моменте перестал писать конкретные комментарии. Далее напишу общим итоговым комментом.
В вашем описании тестировщик сочетает в себе все классы, получается некоторый универсал, который знает сразу все и на уровне специалиста. При этом деление на конкретные штатные единицы существует не просто так. Попытка влезть в чужие вопросы будет восприниматься строго негативно хотя бы потому, что у вас не хватит экспертизы. При этом вы, по сути текста, как раз предлагаете этим заниматься.
Тестировщику платят за тестирование. За тест кейсы, проверку обратной совместимости, выявление багов кроссплатформенности и прочие вещи, которыми просто некогда заниматься разработке и менеджерам.
Тестировщик - важное звено само по себе и не требуется перетягивать на себя чужой функционал, иначе наступит момент, когда вы сломаете чужой ворк флоу при этом не выполнив свой.
Надеюсь мое мнение будет вам полезно и для статей, и в работе :)
А когда работодатель продает труд за 10х это честные условия?
Работодатель продает не труд, а продукт или услугу в стоимость которой может быть вложено несколько человек, а не только вы.
Например, труд менеджера или HR, которые не производят продукт. Там же бухгалтер, налоги, офис и т.п. Куча других проблем о которых вы даже не слышали в силу того, что это не ваша область ответственности.
Если вы считаете, что можете потянуть полный цикл разработки и продажи самостоятельно, то зачем вам работодатель? СМЗ / ИП + фриланс и в добрый путь, таких примеров на рынке достаточно. Иногда они весьма успешные.
Когда работодатель не хочет вкладываться в сотрудников, а только ждет, что они в свободное время повышали свою квалификацию справедливо?
Нет, но и заставить он вас не может так поступать, правда? Развитие (самостоятельное или посредством работодателя) - это дело добровольное, мне кажется :)
А когда работнику недоплачивает, работодатель честно подойдет и скажет: "Чувак, может ты не в курсе, но ты уже сеньер, поэтому вот тебе х2"?
А с чего вы взяли, что вам недоплачивают? На тему самоопределения себя сеньером/мидлом рассуждать не будут - это деление вообще очень условное без четких критериев. Зайду с другой стороны.
У каждой компании есть своя экономическая модель. Где-то будет заложено 100к на разработчика, где-то 200, где-то 800. Это не какой-то фикс, который в каждой компании строго одинаковый и привязан к наименованию "сеньер".
Вы считаете, что вам недоплачивают? А что мешает поступить следующим образом: 1) Берем линейного руководителя на диалог 2) Сообщаем, что на рынке другая стоимость и показываем желание увеличить ЗП. 3) Приводим аргументы (компания А схожая, компания Б схожая, компания С схожая - все ищут сотрудников на Х денег). 4) Даем руководителю время переварить ситуацию и сообщаем, что в случае негативного развития вы начнете искать работу 5) Получаем обратную связь 6) Принимаем решение об увольнении / поиске, если ЗП не подняли.
Опять же, руководитель может быть и рад бы вам повысить ЗП, но экономическая модель может не позволить это сделать. Все очень индивидуально и от компании к компании сильно отличается.
Но адекватным и доброжелательным человеком нужно оставаться всегда.
Из моей практики - много раз пересекался с людьми "из прошлого" уже на новом месте работы. Были бы испорчены отношения - было бы много проблем.
Рынок то весьма узок и взаимодействовать все равно придется, хотите вы того или нет :)
Как раз выше дал схожие рекомендации минуту назад :)
И лично я вот такой ответ как раз считаю полностью адекватным с точки зрения приема на работу.
Но опять же, тут дело вкуса - в каждой компании свои правила и другой может посчитать такой подход недопустимым. Очень сильно зависит от представителя работодателя
У вас нет повода доверять тому что вам говорит кандидат на такие щепетильные вопросы ...
По дефолту у меня нет повода не доверять кандидату. Но в процессе диалога я могу его подловить на лжи и это сразу стоп-фактор существенный для любого работодателя будет :)
Не буду приводить в пример "сферического коня в вакууме", приведу в пример, как действовал я в подобных случаях: 1) Прямой диалог с руководителем. Прямо обозначается, что не устраивает. Либо он услышит и что-то меняется, либо нет. Если руководитель адекватный - попытается решить вопрос.
2) Если не изменилось, то спустя период (обычно 2 недели), подается заявление на увольнение. С этого момента начинается поиск работы.
Итого работодатель примерно за месяц знает о моем желании покинуть компанию.
Все в честных условиях. Я уже ничего не должен старой компании, новый работодатель может не рискуя вести со мной диалог.
2) Что мешает поменять статус на "активный поиск", работая?
Ничего не мешает, но большая часть все же будет целевая :)
Может начальник/владелец/лид самодур и перформанс ревью не проводят или не хотят повышать зп. Истории, когда ушел работать на зп x4, делая по факту тоже самое, совсем не редкие.
Ситуации при которых резюме открывают вполне понятны и критического в этом ничего нет, особенно, если действительно компания состоит из самодуров.
Но это означает, что потенциальный работник уже сейчас подставляет своего работодателя текущего (контекст не столь важен). Получив офер он сорвет разработку на своем уровне, подставив работодателя.
Где гарантия, что через пол года он не посчитает самодуром меня и не повторит кульбит? :)
Можно таких людей брать? Можно. Но они требуют более тщательной оценки личных качеств. Ориентироваться все же стоит на поступки (втихаря ищет работу), а не на слова (начальник был самодур).
Но опять же - это дело вкуса, в другой компании на это вообще могут внимания не обратить, особенно, если задача горит, а делать ее некому :)
У нас более эффективной как раз оказалась система "хантинга", когда мы искали нужного кандидата на площадке. Но да, там утонуть можно быстро, особенно, когда начинаются повторы кандидатов через время.
У меня были простые критерии: 1) Отсеиваем всех, у кого написано, что владеет всем. Владеть всем - нельзя. 2) Статус только "активный поиск". Если человек работает, то хантить его ЗП-шкой не имеет смысла. Сегодня схантил ты, завтра схантят у тебя. 3) Проживание Москва и область. Мы придерживаемся того, что живое общение - важная штука.
Как итог удалось на ~50 вакансий находить 3-5 кандидатов для тех собеса. Из них 1 оставался на выходе с офером.
Заявка сама по себе, к сожалению, давала очень мало лидов :)
У нас зависит от задачи. В большинстве случаев HR подбирает пулл в удобоваримом виде (список резюме с нужных площадок с указанием контактной информации соискателя), а вот отбор делаем сами, чтоб сэкономить всем время.
По итогу для компании это выходит дешевле, даже несмотря на то, что час HR значительно дешевле часа тех лида.
Но если позиция простая, типа "оператор системы" в задачи которого будет входить фоточки щелкать и что-то отмечать/размечать, то тут будет проще HR подключить полноценно.
Это с токсичностью вообще не связано. По крайней мере у нас :)
Токсичность - это что-то формата "вы самая отстойная компания", "я не буду это делать", "все умрут, а я изумруд" и т.п. Т.е. что-то, что вызывает желание не взаимодействовать с таким человеком.
Считается ли токсичностью, когда просишь пояснить кривой комментарий к коду
Тут двоякая ситуация. Если комментатор имеет скил выше, то это может быть элемент обучения. В любом случае, если вам не ясно и комент действительно ценный, то нужно пояснить, чтоб поднять ваш левел. Если комментатор не хочет этого делать - это плохо, значит он пытается на себя замкнуть какую-то экспертизу.
Считается ли токсичностью, когда твою документацию не хотят принимать, пока ты не опишешь полностью алгоритм и способ тех реализации задачи?
Это может быть требование тех лида или заказчика. Тут просто нужно принимать в формате "надо". Да, возможно, что никто никогда не будет это смотреть, но это может быть частью обязательной документации. Из практики, никто никогда не даст время на документирование после реализации - ее лучше сразу подробно готовить. Иначе через N недель для вас ваш же код станет легаси-кодом формата "какой идиот это писал???"
Комплилятору все равно, как написан код - он его прожует. Код и коменты пишутся для людей, чтоб поддерживать можно было долго и упорно. Нет алгоритма в документации - есть шанс понять его работу неправильно.
Считается ли токсичностью, когда на груминге ты просишь не кидаться терминами, которые не уместны и просишь по шагам описать предложенные решения, и продолжаешь настаивать после ответов "ты не поймёшь"?
Опять же, двоякая ситуация. Если вам сказали термин вашего направления ("тут не хватает инкапсуляции", например), а вы не поняли - нужно прокачивать свой скилл.
С точки зрения того, кто этот термин озвучил имеет смысл сразу его пояснить - так быстрее, чем в википедию отправлять.
Если же вас кроют словами типа "серчинг юнита из нашей компьюнити" вместо "требуется найти сотрудника из бэк разработки", то скорее всего у вас проблема. Говорящий пытается показать, что он очень умный и вам до него, как до звезды на черепахе :) Такое тоже встречается нередко.
В целом конечно считается. Да, это токсично, душнила тут определён.
Как написал выше - к токсичности это не имеет никакого отношения. Часть вами описанного - обязательная норма для ИТ, например, читабельная документация или знание терминов.
Другое дело, что если вы только пришли - требовать сразу их знание как минимум странно. В каждой компании своя кухня.
...портит впечатление от новой команды, когда до тебя докапываются из-за опечатке в тексте или если ты не дай бох вставил кросс ссылки на соседние задачи где ты нашёл информацию к своей, ведь и так все всё знают.
Ошибаться можно - врать нельзя. Ошибаются все - это просто нужно принимать как есть.
Аналитик неправильно может понять, что хочет заказчик. Разработчик может неправильно реализовать, даже если описание подробное. Менеджер может неправильно преподнести, даже если реализовано идеально. Тестировщик 100% упустит какой-то баг, который потом стрельнет на проде.
Разработка - это командная игра с взаимным прикрытием :) Ошиблись? Ок. Признали, подумали как поправить, согласовали, начали исправлять, учли в проектах далее.
Требовать "безошибочность" - это очень странный подход и повод задуматься в такой ли компании вы хотели работать :)
Отвергать не будут, но вопрос "С какой целью" станут задавать чаще.
Это хороший вопрос, чтоб поймать нужную нить диалога с соискателем, как хорошую так и не очень: "Интересно было? А какие еще тесты..." "Хотели доказать себе? А в хакатонах вы не участвовали..." "Сертификат дает преимущество при трудоустройстве? Для это он должен быть уровня не ниже..." и т.п.
Стажировка без оплаты - это ерунда. Говорю как представитель работодателя :)
Никто не будет с вами возиться ради того, чтоб научить и отпустить. Обучающий тратит свое время, которое оплачивает компания.
Либо вас изначально учат, вам платят (пусть мало) и пытаются интегрировать в среду компании при этом создав хоть что-то, Либо вас используют, понимая, что вы можете дать готовый продукт бесплатно.
А если вы можете создать такой продукт, почему вы его должны создавать бесплатно? Прислушаться или нет - ваше дело, конечно
Можно короче: 1) Сила в разнообразии 2) Снимите шоры с глаз
А теперь расскажу чуть детальнее взглядом бизнеса, а не одиночки-разработчика.
У вас есть слаженная команда с разным стеком у каждого сотрудника (не знаю ни одной команды, где у всех ровно одни и те же навыки, Майкрософт какой-нибудь может быть, где код на потоке), но при этом с зонами пересечений.
Средний Bus Factor такой компании будет 2+. Т.е. всегда есть тот, кто подменить может.
Приходит новый мидл-сеньер с другим стеком, который не совпадает с командой. Пока он не выучил стек команды Bus Factor резко падает до уровня 1,5, т.е. что-то могут перехватить, а что-то придется ждать того самого новичка сеньера.
Как итог, когда ваш новый сотрудник идет в отпуск / болеет - команда ему названивает по поводу и без, потому что никто не знаком с этим чудо-стеком. И хорошо, если он будет на связи, а не в Сомали где-нибудь на лодках от пиратов бегать.
По сути стремление найти схожий стек - это стремление компании соблюсти баланс и не приводить команду к выгоранию от отсутствия замещающего сотрудника.
Ставить бизнес на стоп во время отпуска/болезни разработчика никто не будет.
Интересная статья :)
В свое время схожим образом автоматизировал через VBA-скрипты, когда множество отделов присылали разнородные данные, которые требовалось нормализовать.
Самое сложное из практики не автоматизировать, а не повредить данные.
Как с этим боролись? :)
Доброго дня!
Прочитал с интересом, есть несколько интересных мыслей.
Дам некоторые комментарии со своей стороны,
возможно, что будет и вам полезно.
Это работает только в одном случае, если аналитик и РП - это одно лицо.
РП - это про общение с заказчиком, требуется навык переговоров.
Его основной инструмент - язык.
Аналитик - это про технику, требуется хорошие понимание того, как можно слова заказчика перевести в технические термины.
Его основной инструмент - технические средства.
И вы далее сами это подтверждаете.
Таким образом вы размываете зоны ответственности и увеличиваете шанс что-то забыть.
Более того, контактным лицом становится не РП, а аналитик - это большая проблема.
А чем в этом случае будет заниматься проектный менеджер? Если один человек тянет функционал вместо двух - это приведет к выгоранию сотрудника.
По итогу не останется ни аналитика, ни менеджера.
При этом далее описываемые преимущества не имеют реальной силы.
Специалист всегда будет лучше, чем "фуллстек".
Вы получите либо "недоменеджера", либо "недоаналитика".
Для стартапа - это приемлемо в силу экономии ФОТ.
Для иных компаний - нет.
Если у вас 2 ставки, то не имеет смысла "делегировать", размывая зону отвественности.
Если у вас 1 ставка, то не имеет смысла рассуждать о том, что аналитик совмещенный с РП - это отлично.
Вы просто работаете с теми реалиями, которые у вас есть в проекте.
Здесь хочется уточнить, а как проект стал хаотичным, если в нем есть и аналитик и РП?
Кто-то из них явно не на своем месте или имеет низкую квалификацию.
Далее как раз вы об этом и пишите, описывая проблемы, которые возникли.
"Пожары" - это ошибка либо аналитика, либо РП, либо обоих сразу.
Ни один из разработчиков не общается с заказчиком, а значит, "сломанный телефон" возник именно на уровне РП / аналитика.
Возможно, что вам стоит побольше пообщаться с командами разработки.
Если аналитик везде будет использовать лучшие практики - проект вообще не запустится.
Задача аналитика не лучшие практики собирать, а найти баланс между "правильно" и "работает".
При необходимости от него же требуется обосновать выбор заказчику.
Затраты на "правильную архитектуру" будут в 2-3 раза выше в силу того, что потребуется очень много всего "поверх работающего кода".
Бизнес не даст на это тратить средства.
Дополнительно бизнес даст DL по сдаче проекта.
Как итог "лучшие практики" заменит обычное "работает - не трогай".
В целом ваша статья выглядит так, что "аналитик" - это "серебряная пуля" или что-то очень близкое к этому.
Ранее встречал у других авторов аналогичные статьи, где "серебряной пулей" выступал РП, тестировщик и т.п.
Если должность существует - это, вероятно, не просто так.
Экономия на РП / аналитике - это экономия на качестве проекта в целом,
причем на самом важном этапе, т.е. сборе требований от заказчика.
Мое личное убеждение, что так делать стоит только в крайнем случае.
В любом случае спасибо за статью - интересная :)
На стартапе да, схожий расклад.
Чем больше человек универсал - тем лучше.
Но опять же, сейчас даже в QA стек такой, что приходится какой-либо профиль выбирать по итогу.
А вот руководители, аналитики и тим лиды как раз должны быть "универсалами", чтоб понимать вектор потенциальных сложностей при разработке.
Иначе, как описал автор,
будет "аналитик не знает, что такое API".
Добрый день, заинтересовало ваше мнение :)
Можете рассказать о случаях, когда экспертиза QA оказалась выше экспертизы разработчика?
Если возможно, то опишите кейс, в котором это произошло.
Так как наша кухня работает чуть иначе, интересно, как это работает у других - может что-то полезное смогу почерпнуть для себя :)
Рад, что в чем-то был полезен :)
Удачи в ваших начинаниях!
Добрый день!
Спасибо за статью, весьма интересное мнение, особенно для первой статьи :)
Пишите, обязательно, еще!
Ниже дал некоторые комментарии как руководитель отдела разработки.
В самом низу есть определенные выводы.
Пишу то, в чем с вами, как автором, не согласен.
Могу быть не прав - везде своя кухня :)
Если хотите, то можем подробно обсудить потом детали - открыт к диалогу,
чем смогу - помогу :)
В данном случае вы видите, скорее всего, лишь часть картины.
Разработчик воспринимает это как критику не потому, что это его ущемляет, а потому, что это "не предусмотрено ТЗ".
Есть задача "собрать автомобиль на 4 человека".
Разработчик это делает.
Следом приходит тестировщик и садится на автомобиль сверху, составляет баг-репорт "проехал сверху - сдувает".
Разработчик идет к бизнес аналитику и спрашивает "а разве это бизнес-кейс?"
Аналитик идет к заказчику, который отвечает "Да, давайте предусмотрим такой вариант, мы про него совсем забыли".
Дедлайн никто не передвинет.
Т.е. то, что вы воспринимаете как негатив к тестировщику на деле является ошибками технического задания.
Эмоции в баг репортах вообще недопустимы и не требуются.
Каждый выполняет работу так, как может.
Иногда кастомизация превращается в "кастылизацию" и с этим ничего не поделаешь.
Есть баг - его требуется описать.
Объяснять почему этот баг это важно - все же не задача тестировщика.
Это больше к руководителю проекта вопрос :)
Вы можете не знать "подкапотья" задумки и поставить высший приоритет вообще не важному багу.
Рекомендую не давать советы по исправлению - это бесит разработчиков :)
У вас недостаточно для этого опыта и в большинстве случаев вы работаете в варианте Grey или Black Box, не понимая особенностей реализации.
Либо ваше место не в тестировании :)
Вы можете дать предположение о причинах формата "тронул модуль А - вылетел модуль Б", вот такой комментарий действительно поможет, он устанавливает причинно-следственную связь и дает предположение о том, где может быть источник.
В каждой компании, конечно, своя кухня...
Однако, если тестировщик даст комментарий формата "вы виноваты",
то первое, что я сделаю как руководитель отдела - это задумаюсь, нужен ли такой тестировщик, который вместо командной игры перекидывает ответственность :)
Попахивает токсичностью очень сильно.
Разработка - это "мы", т.е. нет виноватых вообще.
Есть задача, которую требуется решить в нужный срок.
Все ошибаются и разработчики не исключение :)
Иначе следом можно сказать, что тестировщик пропустил баг в прод.
"Видишь баг?
Нет? Он просто еще не стрельнул!" :)
Не предлагайте, а готовьте.
Одна из важных задач тестировщика подготовить сценарии тестов.
В идеале их лучше иметь на руках до начала разработки, чтоб разработчик на их базе понял в каких местах потребуется валидация данных.
По сути большая часть багов - это не валидированные элементы бизнес-логики.
Но опять же, они должны быть согласованы с руководителем проекта.
Иначе будет история про "погрыз провод - меня ударило током".
Не надо тестировать то к чему не будет доступа у потенциального пользователя.
И не надо мешать тесты производительности, регрессию, ИБ и т.п. с тестами пользователей.
Везде свои особенности.
Откровенно вредный совет.
Вы либо их понимаете, либо нет.
Не надо показывать, что вы их понимаете.
Иначе наступит момент Х, когда ожидание разойдется с реальностью очень сильно.
Все думают, что вы понимаете, а вы "показываете, что понимаете".
Опять же, в каждой компании своя кухня.
Но аналитик требований без знания ИТ?
Это очень серьезная проблема для компании.
Опять же вредный совет.
Его стоит переформулировать так:
"Если не уверены в термине - не употребляйте его вообще, иначе запутаете специалиста".
Смена ТЗ всегда будет вызывать раздражение, без вариантов.
К сожалению.
Причина до банального проста - потерянное время, как итог "горящие дедлайны".
Утешать никого не требуется - это реалии разработки в РФ :)
Если маркетолог хочет добавить анимацию, то его остановит только требуемый бюджет или сроки :)
Маркетологу нет дела тормозит или нет анимация, его задача сделать так, чтоб продукт вызывал нужные эмоции и как итог активнее продавался.
Сделать, чтоб не тормозило - задача разработчика (в данном случае фронт разработчика).
Задача тестировщика, на мой взгляд, не лезть к маркетологу и заниматься тестированием.
Для этого есть линейный руководитель, который, если нужно, донесет нужные мысли горизонтально или вертикально.
Категорическое нет :)
Если он настаивает - руководитель проекта должен обратиться к тим лиду,
тим лид к разработчику,
а разработчик должен придумать метод оптимизации анимации.
Ваш вариант - это вместо решения бизнес-задачи за которую платит ваш заказчик - найти причину "почему мы не справились".
Сейчас вы не реализуете задумку, завтра вам не дадут новый проект.
Все очень просто :)
Кесарю - кесарево, слесарю - слесарево.
Зачем тестировщику лезть в бюджетное планирование? :)
Вы уверены, что ваш комментарий не приведет к пересогласованию бюджета и остановке проекта?
Вы уверены, что ваша методика оценки совпадает с реальными рисками для бизнеса?
Вы уверены, что ...
Бизнес ценит выполнение взятых на себя обязательств :)
Если вы сказали, что сдадите продукт 01.07, а сдали его 01.12 - это очень плохо.
Даже если вы сказали об этом честно 01.06.
На этом моменте перестал писать конкретные комментарии.
Далее напишу общим итоговым комментом.
В вашем описании тестировщик сочетает в себе все классы, получается некоторый универсал, который знает сразу все и на уровне специалиста.
При этом деление на конкретные штатные единицы существует не просто так.
Попытка влезть в чужие вопросы будет восприниматься строго негативно хотя бы потому, что у вас не хватит экспертизы.
При этом вы, по сути текста, как раз предлагаете этим заниматься.
Тестировщику платят за тестирование.
За тест кейсы, проверку обратной совместимости, выявление багов кроссплатформенности и прочие вещи, которыми просто некогда заниматься разработке и менеджерам.
Тестировщик - важное звено само по себе и не требуется перетягивать на себя чужой функционал, иначе наступит момент,
когда вы сломаете чужой ворк флоу
при этом не выполнив свой.
Надеюсь мое мнение будет вам полезно и для статей, и в работе :)
Работодатель продает не труд, а продукт или услугу в стоимость которой может быть вложено несколько человек, а не только вы.
Например, труд менеджера или HR, которые не производят продукт.
Там же бухгалтер, налоги, офис и т.п.
Куча других проблем о которых вы даже не слышали в силу того, что это не ваша область ответственности.
Если вы считаете, что можете потянуть полный цикл разработки и продажи самостоятельно, то зачем вам работодатель?
СМЗ / ИП + фриланс и в добрый путь, таких примеров на рынке достаточно.
Иногда они весьма успешные.
Нет, но и заставить он вас не может так поступать, правда? Развитие (самостоятельное или посредством работодателя) - это дело добровольное, мне кажется :)
А с чего вы взяли, что вам недоплачивают?
На тему самоопределения себя сеньером/мидлом рассуждать не будут - это деление вообще очень условное без четких критериев.
Зайду с другой стороны.
У каждой компании есть своя экономическая модель.
Где-то будет заложено 100к на разработчика, где-то 200, где-то 800.
Это не какой-то фикс, который в каждой компании строго одинаковый и привязан к наименованию "сеньер".
Вы считаете, что вам недоплачивают?
А что мешает поступить следующим образом:
1) Берем линейного руководителя на диалог
2) Сообщаем, что на рынке другая стоимость и показываем желание увеличить ЗП.
3) Приводим аргументы (компания А схожая, компания Б схожая, компания С схожая - все ищут сотрудников на Х денег).
4) Даем руководителю время переварить ситуацию и сообщаем, что в случае негативного развития вы начнете искать работу
5) Получаем обратную связь
6) Принимаем решение об увольнении / поиске, если ЗП не подняли.
Опять же, руководитель может быть и рад бы вам повысить ЗП, но экономическая модель может не позволить это сделать.
Все очень индивидуально и от компании к компании сильно отличается.
Но адекватным и доброжелательным человеком нужно оставаться всегда.
Из моей практики - много раз пересекался с людьми "из прошлого" уже на новом месте работы.
Были бы испорчены отношения - было бы много проблем.
Рынок то весьма узок и взаимодействовать все равно придется, хотите вы того или нет :)
Как раз выше дал схожие рекомендации минуту назад :)
И лично я вот такой ответ как раз считаю полностью адекватным с точки зрения приема на работу.
Но опять же, тут дело вкуса - в каждой компании свои правила и другой может посчитать такой подход недопустимым.
Очень сильно зависит от представителя работодателя
По дефолту у меня нет повода не доверять кандидату.
Но в процессе диалога я могу его подловить на лжи и это сразу стоп-фактор существенный для любого работодателя будет :)
Не буду приводить в пример "сферического коня в вакууме",
приведу в пример, как действовал я в подобных случаях:
1) Прямой диалог с руководителем.
Прямо обозначается, что не устраивает.
Либо он услышит и что-то меняется, либо нет.
Если руководитель адекватный - попытается решить вопрос.
2) Если не изменилось, то спустя период (обычно 2 недели), подается заявление на увольнение.
С этого момента начинается поиск работы.
Итого работодатель примерно за месяц знает о моем желании покинуть компанию.
Все в честных условиях.
Я уже ничего не должен старой компании, новый работодатель может не рискуя вести со мной диалог.
Ничего не мешает, но большая часть все же будет целевая :)
Ситуации при которых резюме открывают вполне понятны и критического в этом ничего нет, особенно, если действительно компания состоит из самодуров.
Но это означает, что потенциальный работник уже сейчас подставляет своего работодателя текущего (контекст не столь важен).
Получив офер он сорвет разработку на своем уровне, подставив работодателя.
Где гарантия, что через пол года он не посчитает самодуром меня и не повторит кульбит? :)
Можно таких людей брать?
Можно.
Но они требуют более тщательной оценки личных качеств.
Ориентироваться все же стоит на поступки (втихаря ищет работу), а не на слова (начальник был самодур).
Но опять же - это дело вкуса, в другой компании на это вообще могут внимания не обратить, особенно, если задача горит, а делать ее некому :)
У нас более эффективной как раз оказалась система "хантинга", когда мы искали нужного кандидата на площадке.
Но да, там утонуть можно быстро, особенно, когда начинаются повторы кандидатов через время.
У меня были простые критерии:
1) Отсеиваем всех, у кого написано, что владеет всем.
Владеть всем - нельзя.
2) Статус только "активный поиск".
Если человек работает, то хантить его ЗП-шкой не имеет смысла.
Сегодня схантил ты, завтра схантят у тебя.
3) Проживание Москва и область.
Мы придерживаемся того, что живое общение - важная штука.
Как итог удалось на ~50 вакансий находить 3-5 кандидатов для тех собеса.
Из них 1 оставался на выходе с офером.
Заявка сама по себе, к сожалению, давала очень мало лидов :)
У нас зависит от задачи.
В большинстве случаев HR подбирает пулл в удобоваримом виде (список резюме с нужных площадок с указанием контактной информации соискателя), а вот отбор делаем сами, чтоб сэкономить всем время.
По итогу для компании это выходит дешевле,
даже несмотря на то, что час HR значительно дешевле часа тех лида.
Но если позиция простая, типа "оператор системы" в задачи которого будет входить фоточки щелкать и что-то отмечать/размечать, то тут будет проще HR подключить полноценно.
Это с токсичностью вообще не связано.
По крайней мере у нас :)
Токсичность - это что-то формата "вы самая отстойная компания", "я не буду это делать", "все умрут, а я изумруд" и т.п.
Т.е. что-то, что вызывает желание не взаимодействовать с таким человеком.
Тут двоякая ситуация.
Если комментатор имеет скил выше, то это может быть элемент обучения.
В любом случае, если вам не ясно и комент действительно ценный, то нужно пояснить, чтоб поднять ваш левел.
Если комментатор не хочет этого делать - это плохо, значит он пытается на себя замкнуть какую-то экспертизу.
Это может быть требование тех лида или заказчика.
Тут просто нужно принимать в формате "надо".
Да, возможно, что никто никогда не будет это смотреть, но это может быть частью обязательной документации.
Из практики, никто никогда не даст время на документирование после реализации - ее лучше сразу подробно готовить.
Иначе через N недель для вас ваш же код станет легаси-кодом формата "какой идиот это писал???"
Комплилятору все равно, как написан код - он его прожует.
Код и коменты пишутся для людей, чтоб поддерживать можно было долго и упорно.
Нет алгоритма в документации - есть шанс понять его работу неправильно.
Опять же, двоякая ситуация.
Если вам сказали термин вашего направления ("тут не хватает инкапсуляции", например),
а вы не поняли - нужно прокачивать свой скилл.
С точки зрения того, кто этот термин озвучил имеет смысл сразу его пояснить - так быстрее, чем в википедию отправлять.
Если же вас кроют словами типа "серчинг юнита из нашей компьюнити" вместо "требуется найти сотрудника из бэк разработки", то скорее всего у вас проблема.
Говорящий пытается показать, что он очень умный и вам до него, как до звезды на черепахе :)
Такое тоже встречается нередко.
Как написал выше - к токсичности это не имеет никакого отношения.
Часть вами описанного - обязательная норма для ИТ, например, читабельная документация или знание терминов.
Другое дело, что если вы только пришли - требовать сразу их знание как минимум странно.
В каждой компании своя кухня.
Ошибаться можно - врать нельзя.
Ошибаются все - это просто нужно принимать как есть.
Аналитик неправильно может понять, что хочет заказчик.
Разработчик может неправильно реализовать, даже если описание подробное.
Менеджер может неправильно преподнести, даже если реализовано идеально.
Тестировщик 100% упустит какой-то баг, который потом стрельнет на проде.
Разработка - это командная игра с взаимным прикрытием :)
Ошиблись?
Ок.
Признали, подумали как поправить, согласовали, начали исправлять, учли в проектах далее.
Требовать "безошибочность" - это очень странный подход и повод задуматься в такой ли компании вы хотели работать :)
Для рекрутера ваши подтверждения пока что ничего не значат.
Никому не понятно как этим пользоваться и нужно ли вообще на что-то ориентироваться.
Отсюда и статья :)
В целом начинание неплохое,
как обычно, вопрос реализации.
Может допилят еще до адекватного состояния :)
Его и напоминает
Отвергать не будут, но вопрос "С какой целью" станут задавать чаще.
Это хороший вопрос, чтоб поймать нужную нить диалога с соискателем, как хорошую так и не очень:
"Интересно было? А какие еще тесты..."
"Хотели доказать себе? А в хакатонах вы не участвовали..."
"Сертификат дает преимущество при трудоустройстве? Для это он должен быть уровня не ниже..."
и т.п.
Стажировка без оплаты - это ерунда.
Говорю как представитель работодателя :)
Никто не будет с вами возиться ради того, чтоб научить и отпустить.
Обучающий тратит свое время, которое оплачивает компания.
Либо вас изначально учат, вам платят (пусть мало) и пытаются интегрировать в среду компании при этом создав хоть что-то,
Либо вас используют, понимая, что вы можете дать готовый продукт бесплатно.
А если вы можете создать такой продукт, почему вы его должны создавать бесплатно?
Прислушаться или нет - ваше дело, конечно
Можно короче:
1) Сила в разнообразии
2) Снимите шоры с глаз
А теперь расскажу чуть детальнее взглядом бизнеса, а не одиночки-разработчика.
У вас есть слаженная команда с разным стеком у каждого сотрудника (не знаю ни одной команды, где у всех ровно одни и те же навыки, Майкрософт какой-нибудь может быть, где код на потоке), но при этом с зонами пересечений.
Средний Bus Factor такой компании будет 2+.
Т.е. всегда есть тот, кто подменить может.
Приходит новый мидл-сеньер с другим стеком, который не совпадает с командой.
Пока он не выучил стек команды Bus Factor резко падает до уровня 1,5, т.е. что-то могут перехватить, а что-то придется ждать того самого новичка сеньера.
Как итог, когда ваш новый сотрудник идет в отпуск / болеет - команда ему названивает по поводу и без, потому что никто не знаком с этим чудо-стеком.
И хорошо, если он будет на связи, а не в Сомали где-нибудь на лодках от пиратов бегать.
По сути стремление найти схожий стек - это стремление компании соблюсти баланс и не приводить команду к выгоранию от отсутствия замещающего сотрудника.
Ставить бизнес на стоп во время отпуска/болезни разработчика никто не будет.
С таким не встречался,
думаю тут вопрос адаптации персонала, так как версии могут очень существенно отличаться по составу.
Как итог, фреймворк знаком, а в нем половина функционала не работает или работает иначе.