тимлидом, который видит только User story, но не видит дизайн-макеты, которые будут реализовывать фронтендеры
и разработчиком, который делает то, что сказали предыдущие 2 человека без права изменений,
То что же в итоге получится? На сколько вообще этот процесс будет гибким? На сколько качественным получится продукт?
Мы за качество и командную работу. Если в работу идут дизайн макеты, то по ним сразу понятен не только внешний вид, но и взаимодействие пользователя с интерфейсом. Максимально эффективно в момент старта работ над этой функцией привлечь все стороны процесса: и аналитика, и фронтендера, и бэкендера.
Аналитик расскажет, как это будет использоваться и зачем это нужно, фронтендеры прикинут, какие методы в какой момент будут дергать, а бэкендеры -- какие данные откуда будут брать и как обрабатывать. На выходе получается оптимальное решение, а не "ну это до меня решили, придется делать как сказали, а не как по-нормальному"
Так что в идеальном мире как раз все участники знают, какую фичу захотел бизнес, зачем он ее захотел, почему мы реализуем именно так и это наиболее оптимальная реализация исходя из всех вводных
Пробовал так тоже сделать, но на сколько я помню, автоматом в гугл мит не получилось залететь, даже если меня пригласили во встречу
Ну и справедливости ради, полноценно пользоваться календарем в таком случае не получится. Приглашения, приходящие на корп почту не будут попадать в этот акк
Если у вашей компании уже есть Google Workspace, то моя инструкция получается не нужна
Настроил отправку писем через мейлрушный SMTP (у нас там корп почта), отправил письмо коллеге на корп почту, всё пришло, в спам не попало
Отправил на другой свой гугловый ящик, тоже пришло, в спам не попало
Ну и самый важный момент -- добавление корп почты как дополнительной не равно получению писем с корп почты и отправки от имени корп ящика. Это просто алиас для гугл акка. Чтобы отправлять и получать нормально надо настраивать интеграцию как с десктопными клиентами, то есть например по POP3 и SMTP
Возможно, вы немного не о том, о чем написано в статье. Инкрементальный подход - это подход, при котором работа над продуктом бьется на инкременты и для каждого инкремента (блока функций) проходится полноценный водопадный процесс: написание полноценной непротиворечивой документации -> разработка -> тестирование
То, что описано в статье это именно подходы к документированию, аспекты в обоих подходах остаются теми же самыми
Документацию можно вести в едином месте и постоянно работать над контролем непротиворечивостью требований ЛИБО просто создавать новые артефакты так, что в них могут быть приняты решения, противоречащие предыдущим артефактам
Не соглашусь и в этом и был посыл статьи -- всё это можно назвать документацией, потому что все эти артефакты описывают поведение системы на разных этапах создания продукта.
Не понимаю вашу логику и не вижу аргументации, почему же нельзя задачи в таск-трекере назвать документацией
Не всё так однозначно, как с родом слова кофе :) Язык -- живая субстанция и тот факт, что этот термин часто употребляется в нашей среде при общении, в статьях и законах именно в том контексте, в котором я его употребил, говорит о том, что рано или поздно просто все признают, что теперь так тоже правильно
Звучит справедливо, но если наладить подходящую схему контрактования и адекватное планирование, то получается хорошо. Особенно, если есть отдельный человек, который может описывать то, что сделали пока другие делают уже следующее
Ну насчет необходимости документации в производстве ракет и ядерных реакторов думаю никто спорить не будет. Но мы с вами не запускаем ракеты в космос (по крайней мере я не запускаю), в продуктах, которые мы делаем важнее дать пользователям продукт, даже если там будет где-то в глубине один хитрый баг. Самолёт не упадет, реактор не взорвется от этого
Вот именно поэтому я и написал эту статью -- многие подходят к задаче написания документации "шоб было", тратят время впустую, а продукт от этого ничего не приобретает или в худшем случае еще и теряет
Вот чтобы переломить ситуацию и чтобы люди не писали документацию, когда не понимают зачем они в данном конкретном случае её пишут я и написал статью
Насчет того, что через год писать документацию скорее соглашусь, но при этом у меня есть много примеров, когда несколько месяцев и даже лет писали систему и когда стало нужно ее передавать другой команде на сопровождение была написана документация. Так что тут тоже дело в целесообразности -- когда она нужна, её нужно писать, когда не нужна -- не нужно
Насчет документации для отдела QA тоже не соглашусь. Каждая задача, которую делал разработчик и которая передается тестировщику должна быть подробно описана. В таком случае само описание задачи и является куском документации. Тоже самое и с техписами -- если есть потребность на каждую функцию написать пользовательскую документацию, то получается это всего лишь еще один пункт в процессе работы над задачей перед ее завершением
"Куда делся документ от Product Management?" -- тут я тоже глубоко убеждён, что прежде чем разработчик приступает к написанию кода у него должна быть подробно описанная задача в таск трекере. Постановщик может вести для себя какие-то дополнительные документы или просто макеты в фигме с описанием пользовательского пути или всё что угодно. Но у разработчика должна быть декомпозированная и описанная задача, а перед стартом нового блока -- весь перечень задач по новому блоку чтобы спроектировать архитектуру
Насчет сваггеров, по которым взаимодействую 2 отдела, разумеется контракты должны выполняться, но это всё равно не значит, что должна быть написана документация. Есть сваггер -- хорошо, нет сваггера, но договорились как тут надо взаимодействовать и в таске написали сигнатуру метода -- тоже нормально. Сама по себе документация не спасёт от того, что нерадивые смежники изменят API к сожалению, это надо решать на уровне процессов.
А насчет того, как отдел узнает, что их модуль не нужен -- ну тут точно вопрос не в документации, а в управлении выше управления конкретным отделом, это тоже должно делаться на уровне процессов. Будет странно, если разработчик прочитает какой-то кусок документации и узнает оттуда, что его отдел не нужен...
Ну исчерпывающую документацию по ненаписанному продукту очень даже можно написать еще до того как продукт создан. Компании, работающие с гос заказчиками делают это постоянно, есть даже отдельный этап -- написание исчерпывающего ТЗ и ЧТЗ по ГОСТу.
Так что не согласен с тем, что это популизм, к сожалению это неприятная действительность
А насчет бухгалтерии -- я в начале статьи писал, что рассказываю о всей документации кроме пользовательской, но сам конечно придерживаюсь подхода, что если к интерфейсу нужна документация, то тут всего 2 причины:
1. Либо пользователь недостаточно "опытный пользователь ПК", как он написал в своем резюме
1. У нас есть программа наставничества, которая не рассчитана на определенный срок, а работает для всех сотрудников на протяжении всего времени работы в компании. На первые 3 года +/- у нас есть прозрачная матрица грейдов, по которой сотрудники двигаются, "закрывая" определенные навыки, задачи, ответственность и самостоятельность.
Четкие пункты есть от стажера до сеньора, после сеньора есть направления, в которых нужно развиваться, чтобы дорасти до тимлида / архитектора и руководителя направления в юните
2. Сотрудников мы берем после школы, которая длится около 2х месяцев. Тех, кто не справился с дипломом, то есть не справился с курсом в полном объеме мы не рассматриваем в качестве кандидатов, а тех, кто справился мы разумеется собеседуем. Собеседования в этом случае необходимы, потому что про выпускника мы знаем только как и с какой скоростью он учится.
При найме для нас важны еще и другие критерии, но если студент лучше других справился с курсом, то мы скорее всего его возьмем к нам работать. Поэтому такой связки - сделал диплом - автоматом зачислился в штат конечно нет
И напоследок, есть ощущение, что я недостаточно понятно описал про нашу схему с наймом, так что если кратко описать, то это будет такая схема:
В зависимости от наличия мест (нам важно, чтобы у каждого стажера был наставник, у которого будет только этот стажер) мы берем лучших по результатам собесов
В течение всей работы в компании сотрудник продолжает быть закреплен за тем же наставником, с которым ставит цели на полгода вперед, встречается не реже чем раз в 2 недели для обсуждения и помощи в достижении этих целей и раз в полгода проводит перформанс ревью (прогресс, достижение целей, профессиональный рост)
Качество обучения разработчиков не сильно изменилось, потому что когда вели курсы в оффлайне, код ревью студентов мы проводили всё-таки онлайн, поэтому в онлайн переместились только лекции
Но пока пришлось приостановить курсы для начинающих менеджеров и аналитиков, специалистов "разговорного" жанра, потому что тут всё-таки важно личное взаимодействие
Если оценивать качество принятых стажеров, то была проблема в том, что при переходе на онлайн и широкую аудиторию мы забыли сделать тоже самое промо, которое мы делали в вузах и поэтому по бэкенду не удалось никого нанять после курса.
В этот раз проблему пофиксили и прикидки по найму и по фронтенду и по бэкенду довольно хорошие, много сильных ребят
Очень обидно, что такой негативный опыт получился у этих подростков :(
Но может они посмотрят на это в конструктивном ключе и в следующий раз будут учитывать в том числе "административный момент" и вместо остановки работы займутся оформлением по правилам взлетающей истории
Это как раз пункт про нативный интерфейс:)
По нашим данным новость на хабре генерирует нам наибольшую долю заявок :)
С вас 20$
Если жестко разделить работу между:
аналитиком, который не будет сам писать этот код,
тимлидом, который видит только User story, но не видит дизайн-макеты, которые будут реализовывать фронтендеры
и разработчиком, который делает то, что сказали предыдущие 2 человека без права изменений,
То что же в итоге получится? На сколько вообще этот процесс будет гибким? На сколько качественным получится продукт?
Мы за качество и командную работу. Если в работу идут дизайн макеты, то по ним сразу понятен не только внешний вид, но и взаимодействие пользователя с интерфейсом. Максимально эффективно в момент старта работ над этой функцией привлечь все стороны процесса: и аналитика, и фронтендера, и бэкендера.
Аналитик расскажет, как это будет использоваться и зачем это нужно, фронтендеры прикинут, какие методы в какой момент будут дергать, а бэкендеры -- какие данные откуда будут брать и как обрабатывать. На выходе получается оптимальное решение, а не "ну это до меня решили, придется делать как сказали, а не как по-нормальному"
Так что в идеальном мире как раз все участники знают, какую фичу захотел бизнес, зачем он ее захотел, почему мы реализуем именно так и это наиболее оптимальная реализация исходя из всех вводных
Если это враньё, то откуда тогда появилось интервью Филиппа, выпускника курса?:)
Пробовал так тоже сделать, но на сколько я помню, автоматом в гугл мит не получилось залететь, даже если меня пригласили во встречу
Ну и справедливости ради, полноценно пользоваться календарем в таком случае не получится. Приглашения, приходящие на корп почту не будут попадать в этот акк
Спасибо, изучу подробности
Если у вашей компании уже есть Google Workspace, то моя инструкция получается не нужна
Настроил отправку писем через мейлрушный SMTP (у нас там корп почта), отправил письмо коллеге на корп почту, всё пришло, в спам не попало
Отправил на другой свой гугловый ящик, тоже пришло, в спам не попало
Ну и самый важный момент -- добавление корп почты как дополнительной не равно получению писем с корп почты и отправки от имени корп ящика. Это просто алиас для гугл акка. Чтобы отправлять и получать нормально надо настраивать интеграцию как с десктопными клиентами, то есть например по POP3 и SMTP
Отвечу по пунктам:
Речь о документации вида юзерстори, юзкейсах, ЧТЗ
Возможно, вы немного не о том, о чем написано в статье. Инкрементальный подход - это подход, при котором работа над продуктом бьется на инкременты и для каждого инкремента (блока функций) проходится полноценный водопадный процесс: написание полноценной непротиворечивой документации -> разработка -> тестирование
То, что описано в статье это именно подходы к документированию, аспекты в обоих подходах остаются теми же самыми
Документацию можно вести в едином месте и постоянно работать над контролем непротиворечивостью требований ЛИБО просто создавать новые артефакты так, что в них могут быть приняты решения, противоречащие предыдущим артефактам
Не соглашусь и в этом и был посыл статьи -- всё это можно назвать документацией, потому что все эти артефакты описывают поведение системы на разных этапах создания продукта.
Не понимаю вашу логику и не вижу аргументации, почему же нельзя задачи в таск-трекере назвать документацией
Не всё так однозначно, как с родом слова кофе :)
Язык -- живая субстанция и тот факт, что этот термин часто употребляется в нашей среде при общении, в статьях и законах именно в том контексте, в котором я его употребил, говорит о том, что рано или поздно просто все признают, что теперь так тоже правильно
Слышу боль госухи и фикс прайс проектов:)
Звучит справедливо, но если наладить подходящую схему контрактования и адекватное планирование, то получается хорошо. Особенно, если есть отдельный человек, который может описывать то, что сделали пока другие делают уже следующее
Тут соглашусь. Манифест говорит не об обязательности или необязательности, а о том, что важнее, чему должен отдаваться приоритет
Ну насчет необходимости документации в производстве ракет и ядерных реакторов думаю никто спорить не будет. Но мы с вами не запускаем ракеты в космос (по крайней мере я не запускаю), в продуктах, которые мы делаем важнее дать пользователям продукт, даже если там будет где-то в глубине один хитрый баг. Самолёт не упадет, реактор не взорвется от этого
Вот именно поэтому я и написал эту статью -- многие подходят к задаче написания документации "шоб было", тратят время впустую, а продукт от этого ничего не приобретает или в худшем случае еще и теряет
Вот чтобы переломить ситуацию и чтобы люди не писали документацию, когда не понимают зачем они в данном конкретном случае её пишут я и написал статью
Насчет того, что через год писать документацию скорее соглашусь, но при этом у меня есть много примеров, когда несколько месяцев и даже лет писали систему и когда стало нужно ее передавать другой команде на сопровождение была написана документация. Так что тут тоже дело в целесообразности -- когда она нужна, её нужно писать, когда не нужна -- не нужно
Насчет документации для отдела QA тоже не соглашусь. Каждая задача, которую делал разработчик и которая передается тестировщику должна быть подробно описана. В таком случае само описание задачи и является куском документации. Тоже самое и с техписами -- если есть потребность на каждую функцию написать пользовательскую документацию, то получается это всего лишь еще один пункт в процессе работы над задачей перед ее завершением
"Куда делся документ от Product Management?" -- тут я тоже глубоко убеждён, что прежде чем разработчик приступает к написанию кода у него должна быть подробно описанная задача в таск трекере. Постановщик может вести для себя какие-то дополнительные документы или просто макеты в фигме с описанием пользовательского пути или всё что угодно. Но у разработчика должна быть декомпозированная и описанная задача, а перед стартом нового блока -- весь перечень задач по новому блоку чтобы спроектировать архитектуру
Насчет сваггеров, по которым взаимодействую 2 отдела, разумеется контракты должны выполняться, но это всё равно не значит, что должна быть написана документация. Есть сваггер -- хорошо, нет сваггера, но договорились как тут надо взаимодействовать и в таске написали сигнатуру метода -- тоже нормально. Сама по себе документация не спасёт от того, что нерадивые смежники изменят API к сожалению, это надо решать на уровне процессов.
А насчет того, как отдел узнает, что их модуль не нужен -- ну тут точно вопрос не в документации, а в управлении выше управления конкретным отделом, это тоже должно делаться на уровне процессов. Будет странно, если разработчик прочитает какой-то кусок документации и узнает оттуда, что его отдел не нужен...
Ну исчерпывающую документацию по ненаписанному продукту очень даже можно написать еще до того как продукт создан. Компании, работающие с гос заказчиками делают это постоянно, есть даже отдельный этап -- написание исчерпывающего ТЗ и ЧТЗ по ГОСТу.
Так что не согласен с тем, что это популизм, к сожалению это неприятная действительность
А насчет бухгалтерии -- я в начале статьи писал, что рассказываю о всей документации кроме пользовательской, но сам конечно придерживаюсь подхода, что если к интерфейсу нужна документация, то тут всего 2 причины:
1. Либо пользователь недостаточно "опытный пользователь ПК", как он написал в своем резюме
2. Либо интерфейс плохо спроектирован
Статья написана ChatGPT? :)
Отвечу по пунктам:
1. У нас есть программа наставничества, которая не рассчитана на определенный срок, а работает для всех сотрудников на протяжении всего времени работы в компании. На первые 3 года +/- у нас есть прозрачная матрица грейдов, по которой сотрудники двигаются, "закрывая" определенные навыки, задачи, ответственность и самостоятельность.
Четкие пункты есть от стажера до сеньора, после сеньора есть направления, в которых нужно развиваться, чтобы дорасти до тимлида / архитектора и руководителя направления в юните
2. Сотрудников мы берем после школы, которая длится около 2х месяцев. Тех, кто не справился с дипломом, то есть не справился с курсом в полном объеме мы не рассматриваем в качестве кандидатов, а тех, кто справился мы разумеется собеседуем. Собеседования в этом случае необходимы, потому что про выпускника мы знаем только как и с какой скоростью он учится.
При найме для нас важны еще и другие критерии, но если студент лучше других справился с курсом, то мы скорее всего его возьмем к нам работать. Поэтому такой связки - сделал диплом - автоматом зачислился в штат конечно нет
И напоследок, есть ощущение, что я недостаточно понятно описал про нашу схему с наймом, так что если кратко описать, то это будет такая схема:
Студенты проходят курс по бэкенду или курс по фронтенду в течение 1-2 месяцев
Лучших выпускников мы собеседуем
В зависимости от наличия мест (нам важно, чтобы у каждого стажера был наставник, у которого будет только этот стажер) мы берем лучших по результатам собесов
В течение всей работы в компании сотрудник продолжает быть закреплен за тем же наставником, с которым ставит цели на полгода вперед, встречается не реже чем раз в 2 недели для обсуждения и помощи в достижении этих целей и раз в полгода проводит перформанс ревью (прогресс, достижение целей, профессиональный рост)
Спасибо за вопрос!
Качество обучения разработчиков не сильно изменилось, потому что когда вели курсы в оффлайне, код ревью студентов мы проводили всё-таки онлайн, поэтому в онлайн переместились только лекции
Но пока пришлось приостановить курсы для начинающих менеджеров и аналитиков, специалистов "разговорного" жанра, потому что тут всё-таки важно личное взаимодействие
Если оценивать качество принятых стажеров, то была проблема в том, что при переходе на онлайн и широкую аудиторию мы забыли сделать тоже самое промо, которое мы делали в вузах и поэтому по бэкенду не удалось никого нанять после курса.
В этот раз проблему пофиксили и прикидки по найму и по фронтенду и по бэкенду довольно хорошие, много сильных ребят
Хотелось бы больше узнать про эволюцию доставки и раскатки апдейтов на самокаты и как поступали в случаях, когда нужно катить хотфикс
Очень обидно, что такой негативный опыт получился у этих подростков :(
Но может они посмотрят на это в конструктивном ключе и в следующий раз будут учитывать в том числе "административный момент" и вместо остановки работы займутся оформлением по правилам взлетающей истории