Comments 52
This publication could cause conflicting feelings. Be critical of any posted information. Remember the Community Guidelines before posting your comment.
How to write and what to do?
- Don`t write offensive comments or get personal.
- Refrain from obscene language and toxic behavior, even in a veiled form.
- o report comments that violate the rules of the site, click the "Complain" button or fill out the feedback form.
What to do if: karma goes down, the account is blocked.
Крушение менеджерских фантазий суровой правдой разработки в реальном мире :)
Фантазия: "декомпозируем, проектируем, документируем, согласовываем с заказчиком четкий срок, разрабатываем, укладываемся в спеку и срок, все счастливы, готово".
Реальность: в начале получаем векторное понимание проекта, по ходу дела вместе с заказчиком и командой разбираемся в деталях, переписывая и переделывая из-за недопонимания заказчиком/командой реально происходящих процессов, и процессов которые должны происходить (нередко таким образом чиним бизнес процессы заказчика), мискоммуникации, приходим к MVP, релизим, уточняем требования, получив новые знания о проекте и требованиях в ходе "проверки боем", переписываем заново с учетом новых требований, релизим, саппортим. На каждом этапе боремся с мискоммуникацией со всей силы.
Статья пропитана реальным опытом и пониманием процессов "изнутри", тем и ценна.
Спасибо.
Именно так, рад что кто-то, кроме меня знает, что такое агиле.
Мне кажется, этот способ станет стандартом и все к нему привыкнут
Исполнитель и заказчик будут понимать что цена "векторному направлению проекта вместо четкого ТЗ" - сложность в коммуникации
При этом бизнесу выгодно формат бег ТЗ, где можно на ходу менять цели и вообще направление. Рынок ведь тоже не стоит на месте, конкуренция растет, и выигрывает тот, кто быстрее решит новые проблемы клиентов. А когда проблемы устаканены, можно уделить внимание "красоте архитектуры"
Очень странная статья, с высосанными из пальца тезисами, которые автор тут же бросается аргументировать. Крайне похоже, что кто-то заказал опубликовать негатив про Селектел, причем с самой компанией, судя по всему, этот автор вообще не знаком.
P.S. Посмотрел, пару дней назад была опубликована еще одна статья с негативом против Селектела, причем сделано топорно - типа выбрали несколько компаний, для всех прочих отметили малюсенькие недостаточки, по Селектелу прошлись огнем и мечом. Неделя проплаченного негатива против этой компании объявлена? ) Очень все шито белыми нитками, ребят. Не надо так.
Проплаченная компания...
Высосанная из пальца...
Прошу прощения, но вы звучите как сотрудник селектела.
Под этим постом нет и двух тысяч просмотров, а вы уже накрутили 14 плюсов под свой комментарий.
Если вы действительно сотрудник, должен вам сообщить, в своих накрутках вы не знаете берегов.
Ну и снова то же самое - высосанный из пальца тезис и тут же обвинение. Насчет "не знаете берегов" - тут уже какой-то жаргон пошел, простите, но я в таком стиле не общаюсь.
Эдак мы дойдем с вашей стороны до: "Ты из какого района?" :)
Насчет плюсов - возможно, просто статья реально странно выглядит и читатели плюсуют адекватный комментарий? Но это лишь мое предполжоение. На этом дискуссию считаю оконченной, я отвечать больше не буду.
кто-то заказал опубликовать негатив про Селектел,
… еще одна статья с негативом против Селектела
сделано топорно — типа выбрали несколько компаний, для всех прочих отметили малюсенькие недостаточки
Неделя проплаченного негатива против этой компании объявлена? ) Очень все шито белыми нитками, ребят.
ну вы реально же сотрудник Селектела?
вы же отвечаете в стиле "ответа бизнеса" в комментариях к продуктам маркетплейсов в стиле "пошли вон злые конкуренты!!"
даже если это реально проплаченный антипиар, очень странно что именно вас (если вы мимокрокодил) это прям зацепило.
По селектелу прошлись огнем и мечом с данными тестов. Любой заинтересованный может повторить эти тесты и удостовериться или опровергнуть их.
Очень странная статья,
...однако, весьма характерная именно для этого автора своей провокационностью: посмотрите его публикации (и среди них есть одна явно непроплаченная - про слитые сорсы). Кстати, я бы на месте НЛО тут бы перед каментами плашку бы поставил, ту, которая про "противоречивые чувства".
Крайне похоже, что кто-то заказал опубликовать негатив про Селектел
Проверьте свою гипотезу: например, посмотрите, нет ли подобных статей на других аналогичных ресурсах, типа vc.ru. И, пожалуйста, сообщите результаты проверки (мне будет интересно - vc.ru я, например, не читаю, потому что он - не для технарей) .
Учтите, что есть и альтернативная гипотеза появления этой статьи: накрутки плюсов в корпоративных блогах реально достали (меня, например - тоже, и, гляжу в каменты - не только меня). Только вот большинству тех, кому накрутки не нравятся, писать статью по такому поводу либо лень, либо некогда. Но, вот, в результате, нашелся человек, который решил-таки выразить свое отношение к Селектелу: нашел и расккритиковал статью, где Селектел явно подставился.
ухудшенной версия ватерфолла
это называется "ватерфейл"
Отличная статья. Во-первых, я очень рад, что кто-то снова поднял вопрос голосов в корпоративном блоге. Я одно время даже сидел и ковырял статистику, благо хабр отдает все посты по JSON API со всеми полями. Там много интересного, но статью таки писать стало лень. Айтишный ресурс не способен бороться с накруткой, хотя достаточно банально посмотреть на распределение просмотров лайков во времени после выхода (а у некоторых корпоративных блогов +10 сразу после публикации, чтобы на главную попасть), и на коэффициент лайков к просмотрам. Собственно, достаточно зайти в профильные хабы, чтобы посмотреть, какие крутые статьи там висят с низким рейтингом, зато на главной 10 видов лечения зубов и почему аборигены съели Кука.
А во-вторых, я уже продолжительное время вижу нарастание менеджерского безумия. Вероятно, это связано с тем, что разработчиком стать все-таки сложнее, нужно иметь склад ума инженерный, способности и теорию, с менеджерскими позициями все проще. И начинается какой-то цирк с конями, лишние телодвижения, 10 митапов в неделю на разные темы, потому что так надо, стендапы, игры в ДНД в обязательном порядке, корпоративные обливания водой в день Нептуна, танцы и пляски и другие проявления современных методологий управления персоналом. И все бы ничего, ладно, но все это на фоне горящих дедлайнов. И все больше менеджеров я вижу, которые не в состоянии ТЗ составить, оценить время, договориться о чем-то с заказчиком, зато знают 1000 и 1 способ отвлечь разработчика от работы.
а можно лучше БДСМ?
БДСМ хотя бы заявляет о трех главных принципах: безопасности, добровольности, разумности. Чего не скажешь о корпоративной разработке...
Предлагаете добавить в процессы стоп-слово?
Ага. И aftercare после двухчасовых совещаний.
Отдельный cuddle-ing room на выходе из meeting dungeon?... Звучит разумно, добровольно, главное чтоб SFW.
Каждый раз поражаюсь широте познаний айтишников. Даже, казалось бы, в сферах, далеких от профессии.
Мне рассказывали как выглядел отдел девушек-"божьих одуванчиков" в Яндексе, занимающихся классификацией NSFW картинок и поисковых запросов для детской фильтрации.
Я лично наблюдал примерно такую же картину в виде милейших созданий, которые извиняющимся тоном говорили: "у нас нету в лаборатории молотков... вот, разводной ключик, мы им мышек подготавливаем" (ключ весом килограмма в 2 весь бурый от запекшейся крови -- они реально мышек к исследованиям после экспериметов им "подготавливают")...
Короче, не надо встречать по профессии :)
Непонятно, что сказать то хотели? Что у них все плохо? И зачем приплетать свой опыт разработки к отчетности?
Все, у кого есть мозг и все, кто умеют свой мозг думать, понимают, что чем больше у тебя работы, тем больше на тебе нагрузка.
Не совсем так. Работа состоит из много чего: проектирование, реализация, тестирование, приемка. А когда это все делает один человек, все становится намного сложнее из-за когнитивной нагрузки.
Чтобы хоть как-то ее снизить и решили выстроить конвеер, по крайней мере отделив техничку от бизнеса. Причем это стандартный прием в такого рода командах по мере их роста.
Если вы делаете весь дизайн наперед как Нукси это делает, за эти поставленные 2 недели не написана ни одна строчка кода. Это не только трата времени на дизайн, который не взлетит, но дизайн, который априори не исходит из реалий стека и языка.
Ох как поспорил бы с вами Самый лучший программист Deadline ДеМарко...
Вообще странно, судить о процессах работы компании на примере описания процесса внутренней команды, которая занимается созданием дашбордов для внутренних нужд с множеством заказчиков, у которых могут быть разные требования к одним дашбордам, данным и т.д.) Скажем так, это мягко говоря не классическая разработка, а уж тем более не продуктовая разработка продуктовой команды.
Но, тем не менее, описанные изменения в этой команде улучшили их жизнь, а возможно и жизнь их заказчиков, соответственно цель изменений была достигнута. Процессы подстраиваются под контекст, серебряной пули тут нет.
Привет! Очень здорово, что мой текст так вас заинтересовал. Стиль письма животрепещущий)
Мы делали процесс, опираясь на возникшие трудности и собственный опыт. → Изменения нам помогли, ни один разработчик или заказчик при этом не пострадал ? Понимаю, что в контексте вашего опыта выводы могут быть иные. Интересно, где и кем вы работаете, что появилась такая нелюбовь к менеджерам?)
Я, в свою очередь, тоже рад, что мой текст заинтересовал вас. Надеюсь, моя статья поможет вам сформировать альтернативный взгляд на вашу работу.
ни один разработчик или заказчик при этом не пострадал ?
А расскажите, как вы это установили?
Отвечу за автора, поскольку она не очень хочет участвовать в этом диалоге. В команде всего 10 человек, спросить об удовлетворенности процессами несложно. А в Selectel одна из ценностей — открытый фидбэк и прозрачность коммуникаций.
Разработчикам из команды BI-аналитиков текст уважаемого nneeoo не понравился) К слову, ребята поддерживают нашего автора и говорят, что с изменениями процессы стали намного лучше. Цитировать здесь не буду, поскольку это частная переписка.
У автора статьи здесь явно бомбит и очень сильно, да. Формат изложения мыслей не из лучших, да. Однако же вы при этом не услышали главной мысли статьи -- согласно внешнего осмотра, имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монстру. И этого даже и не заметили.
Нужен полноценный рефакторинг, а не поза "у меня всё работает"
имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монстру
Это вы так неочевидно обыграли проблему "жадных" алгоритмов? Или я неправильно интерпретировал?
В смысле, неочевидно?
Неочевидно в моем понимании, это когда рядовой выпускник школы - не поймет. Но вообще да, нужно было уточнить, неочевидно для меня, я не смог однозначно понять, что имелось ввиду. Поэтому прошу все же ответить на вопрос, объяснить что имелось ввиду в более простых формулировках
Взяли процесс организации труда и неумело его вкорячили. Резонно огребли проблем и сложностей. Начали проблемы решать по очереди и по одной. На выходе получили процесс-химеру, который не должен существовать.
Как участники процесса преобразования - не заметили, что родили монстра.
Да, жадные алгоритмы приводят к такому. "жадные" в данном случае могут иметь десяток трактовок но это уже не специально.
Не хочу разбираться в бизнесе Selectel, но хочу заметить, что Agile в варианте Scrum слабо применим там, где нужен конвейер и сроки. Этим объясняется частая трансформация Скрама в водопад. А мимикрия получившегося водопада под Agile объясняется желанием менеджеров "быть в тренде".
С одной стороны вся критика в статье правильная, с другой стороны похоже автор сам сторонник бюрократии, тдд - та же бюрократия. Стоит разработке стать чуть более алгоритмической или МЛ, и с тдд будут те же проблемы что и с бюрократией из статьи.
Я не очень понимаю, каким именно образом аналитики из оригинальной статьи превратились в менеджеров. Аналитики - такие же работники, как и программисты, находятся примерно на том же уровне пищевой пирамиды. Не вижу ничего крамольного в выделении аналитиков в отдельную подкоманду при условии плотного взаимодействия с разработчиками. Лично я читаю слово «методолог» как «эксперт», эксперт в том, что программист не знает. Когда вы пишете бухгалтерский софт, вам нужен эксперт области, методолог, аналитик - как угодно. Иначе программисту придется изучать бухгалтерию. Если это отчеты - нужен методолог, который знает как это отчеты читаются в первую очередь, а не как строятся.
Также не очень понимаю, почему у автора бомбит от дачи сроков заказчику. Подписание любого контракта подразумевает подписание его на определенный срок, в течение которого работа должна быть выполнена. Нормальный адекватный процесс при этом подразумевает возможность их изменения, но в любом случае все начинается со сбора требований, их грануляризации и оценки.
Отдельным пунктом идет идея о том, что заказчику необходимо знать сроки. А деньги вам платят тоже за сроки?
В любом случае заказчику необходимо понимать, когда он это получит, чтобы подстроить свои процессы. Обеспечить железо, подготовить работников - это все не появляется ниоткуда, а требует расчета бюджета, амортизации, подготовки. Не только исполнитель делает работу, но и заказчик со своей стороны тоже.
Ну и главный мой вопрос - а как надо? Я, например, так и не понял.
Уважаемые nneeoo, спасибо, что уделили столько внимания тексту в нашем блоге. Интересно, что вы расчехлили свой токсикомет именно на наш блог — с нетерпением жду ваших следующих текстов. Ведь про оптимизацию процессов и работу в команде корпоративные блоги на Хабре пишут довольно часто. Уверена, с учетом вашего стиля «возьму абзац и напишу свое фи» у вас получится не менее вдохновляющие публикации, направленные на хайп :)
Что бы вы ни писали, изменения, которые ребята реализовали в команде, для них сработали. Возможно, они сработают для кого-то еще. Заметьте, что в тексте наш автор не писала, что это догма для всех.
Надеюсь, у вас есть работа, где вы используете ваши глубокие знания о менеджменте в разработке. Возможно, стоит встать с места диванного критика и рассказать, как правильно все устроено именно у вас в команде. Мы обязательно возьмем на заметку. Всего хорошего)
Спасибо что уделили время моей токсичной проплаченной статье!
Надеюсь, деньги моего заказчика смогут улучшить положение дел в вашей компании!
Судя по стилю комментария Вы относитесь к рукодству компании. Не касаясь сути статьи хотелось бы услышать Ваше мнение по-поводу накрутки рейтингов . Фактически Ваши сотрудники вводят Вас в заблуждение, несколько "приукрашивая" свои достижения в ведении корпоративного блога.
Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
программисты баз данных
кто такие программисты баз данных? вы про DBA?
кто такие программисты баз данных?
вполне себе существуют программисты на PL/SQL
И крупные корпоративные продукты где большая часть бизнеслогики находится в хранимых процедурах БД
p.s. не буду судить хорошо это или плохо, это факт, в финсекторе такое видел
DBD
Один из моих любимых вопросов на собеседовании: чем можно заменить триггер на табличку в БД?
Можем порассуждать вне контекста хранимых процедур?
Зависит от кучи переменных в имеющихся требованиях.
Например, может быть решено через:
Код в ORM слое
Можно повесить Server-side сниффер или прокси
Если не срочно -- то от Diff между бакапами до фонового сканнера
Ну и никто не мешает просто всегда в транзакции делать все вещи вручную. Иногда это еще и лучшее решение...
Зависит от СУБД. Например c MySQL можно использовать ProxySQL, а там используем правила =)
А вообще тут просто такой вопрос - уверены ли мы, что все наши write коннекты будут идти через ORM / ProxySQL / любое третье решение?
У меня сейчас ситуация, когда к 1 БД подключаются легаси приложения и новые приложения, большинство через ProxySQL, но есть и прямые коннекты, в БД творится некий ужас.
вообще тут это явно Дата инженеры
Заголовок в ленте был виден не полностью, предположил, что речь о гугле - у них довольно много чудовищных проколов в элементарных функциях, так бывает, если разработчик не знает, что он делает, кроме своей части, а сводит все менеджер)
Из текста совершенно не понятно как автор предлагает построить работу. Если отталкиваться только от отрицания, то есть подходов, которые считаются неправильными с точки зрения автора, выходит следующая картина:
Разработчик, без аналитиков и менеджеров, рука об руку с заказчиком, без сроков и технического задания, вместе делают проект, который решает проблемы
Звучит как эталон agile, классно, вероятно в каких то проектах это может работать, но есть огромное количество других, где такой подход невозможен.
И в этих, других проектах, существует всё то что автор считает невозможным:
Там заказчик платит за сроки, а не за результат
Там менеджер 2 недели придумывает как должен работать проект, потому заказчик даже писать не может ничего длиннее 2 строчек
Там вал тех самых проблем и неточностей выявляются на этапе ТЗ и дизайна
Там разработчик не хочет видеть, слышать заказчика, а делать проект по +- четкому ТЗ
Там разработка не только написание кода, но и момент аналитики и проектирования решения
В целом, гнев автора статьи понятен, но создается впечатление что столь яростное обвинение складывается из глубокого, но узкого опыта работы.
Мир разный и нужно использовать те инструменты, которые подходят для решения поставленной задачи.
Убийство разработки: опыт Selectel