Комментарии 26
Разрабатывал самую, наверное, важную часть продукта и занимался этим годами. Но никакого внятного тестирования и вообще контроля его работы не было. В итоге человек вместо релиза выкатил непонятное глючное нечто,
Как это возможно вообще? Годами писал и выкатил один релиз?
Как это возможно вообще? Годами писал и выкатил один релиз?
"Водопад".
Кто-то где-то когда-то написал ТЗ (за полгода) размером с книгу или две, потом программист или несколько написали по ТЗ какую-то программу. За полгода, год, или даже два.
Потом это как бы отдали на тестовую эксплуатацию и тут могут быть нюансы (в зависимости от усердности этой тестовой эксплуатации). Наконец, релиз, NN или даже NNN рабочих мест на новой программе с понедельника - и вот тут приходит он - полярный лис.
Вы так говорите, как будто водопад это что-то плохое. Никто не мешал этому менеджеру разбить разработку на майлстоны и время от времени проверять ход работ, вместо того, чтобы делать круглые глаза в финале.
Проверять менеджером и проверять релизом на реальных пользователях - сильно разные вещи.
Если ИС монолитна, разработка ведется водопадом - в конце будут круглые глаза.
А успех измеряется диаметром круглых глаз. Чем меньше диаметр, список багов и список доработок "вы не так поняли ТЗ" - тем успешнее релиз, и, в целом, проект :)
У водопада есть недостатки. В частности, повышенная ответственность на каждом этапе, потому что цена ошибки возрастает - и чем раньше совершена ошибка, тем сильнее. Поэтому требуется высокая дисциплина участников проекта.
У аджайла, напротив, дисциплина вообще может отсутствовать. В следующем спринте "как-нибудь" исправят, как-нибудь добавят и как-нибудь пофиксят. Кек.
Это не ответ. Если это самая важная часть системы, то почему она пилилась годами одним человеком и всем было всё равно что там? Что то не договаривают
Зависит от ситуации. Всю правду нам тут всё ровно не расскажут.
Просто я присутствовал при таком однажды (биллинговая система предприятия в сфере ЖКХ), вот там всё так и было. Программистов было несколько, но каждый отвечал за свой участок: у кого-то ядро, у кого-то отчеты и печатные формы, у кого-то АРМы операторов.
Я ж не против разбиения по разработчикам. Ваш программист, отвечающий за ядро, мог писать код два года и не релизить ничего? Явно все отчеты/формы/... дёргают что то из ядра
Тут-то человеку и высказали всё, что о нём думают, не стесняясь в выражениях, и отстранили от фактической разработки.
Вот это ещё шедеврально. Понятно, что разраб мог пошевелиться в сторону тестирования, качества, процессов, но это жесть какая то.
Там дергали из БД, БД была предзаполнена.
Водопад это аджайл с одной единственной итерацией. Видел такое когда разработкой руководили люди далекие от программирования. Для них концепция: "Давайте все заранее продумаем и запланируем. А потом просто разделим на куски и раздадим людям. И конечно чтобы все сразу заработало", при этом не имея до этого обширного опыта в заданной области. Не выглядела абсурдно.
В Италии, например, прямолинейный фидбек не приемлем, проверено. Принцип гамбургера используется не только в отношениях начальник-подчиненный, а вообще в повседневной жизни, когда нужно сообщить нечто неприятное. Это неприятное всегда оборачивается в приятную обертку. Такая культура, отход от канонов вежливого разговора считается невежливостью.
А вот интересно, а если человек не согласен с такой критикой? Хороший специалист может доказать, что работа сделана качественна (если он действительно делал на совесть). Как будет тогда чувствовать себя менеджер, если окажется, что разработчик прав, а он - нет? Фэйлы не случаются на ровном месте, для них всегда есть признаки. И хороший менеджер этого не может не видеть. Если такой неприятный разговор произошёл, то виноваты оба. Почему обсуждается вина только разработчика? А его руководителя?
А если человек избегает обратной связи?
На вопрос как дела, ответ — всё хорошо!
Успеваем — а как же, конечно и т.д.
А когда приходит время, выясняется, что работа не сделана.
И оправдания — я не успел, я не знал как…
Как внушить человеку, что самое плохое — это подвести, что лучше вовремя отказаться от задания, что незнание устранимо и т.д.
Если вам информации не хватает от человека, нужно ее вытягивать более конкретными вопросами.
– Как дела?
– Все хорошо.
– Что именно хорошо? Что конкретно сделано за <промежуток времени>? Сложностей/стоперов никаких сейчас нет? Всего хватает для выполнения задачи?
...
– Успеваем?
– Конечно!
– А что успел сделать? А что осталось? Асколько тебе времени на каждую из этих задач надо? Какие могут сложности возникнуть?
Ну и тестирование задач не только самим человеком, но и отдельным тестировщиком/аналитиком, который погружен в систему – без этого тяжковато будет.
– Успеваем?
– Конечно!
- А что успел сделать? А что осталось?
А что ты успел сделать за этот же промежуток времени?
А спрашивающий кого имеет в виду под "успеваем?" Он так спрашивает, словно принимал участие в разработке и не понял, что успевает или не успевает? Может надо поменьше употреблять слово "мы" задавая вопросы, к которым не имеешь отношения от слова никак?
Что за мода пошла? На словах проявлять участие, а на деле вежливо вытирать о человека ноги.
А когда приходит время, выясняется, что работа не сделана. ... Как внушить человеку ...
Я сам попадал в такое в роли работника. В принципе как менеджер всех за ручку не поводишь, и просто на словах внушить такое челоеку не всегда возможно.
В тот момент мой руководитель сделал на мой взгляд самое правильное - дал мне зафейлить на не слишком важной задаче, и далее провёл разбор полётов - с правильной критикой и "обратной связью". И тогда я сам понял и "проникся" тем, как надо в таком случае действовать в следующий раз.
Если человека взяли на работу, и он прошёл испытательный срок — он профпригоден.
Зависит от уровня нанимающего человека. Попал в ситуацию, когда в команде 2 "мидла", 1 тимлид, 1 QA. Несколько сервисов, отсутствие понимания SOLID и полностью отсутствие каких либо тестов. QA к описанию багов прикладывал скриншот логов.
нужно говорить о работе и о себе, а не о другом человеке
— Вы правы, я не успел купить стол и оборудование для рабочего места. Только лампу и чашку принёс.
измеряйте ошибки
— Вы правы, я за месяц ничего не сделал. Это потому что не успел купить стол и оборудование для рабочего места.
выявляйте причины и объясняйте последствия
— Моя зарплата не позволила купить и компьютер, и стол, и монитор, и смежное оборудование, и удлинитель, и клавиатуру за один месяц. Я их сразу куплю, как только накоплю денег.
используйте вежливые формы
— Спасибо. Да, здесь ошибка. Надо было сначала накопить денег, а потом искать работу.
нужно говорить о работе и о себе, а не о другом человеке
"Код ты пишешь так себе" — примеры деструктивной критики.
"Мне бы хотелось, чтобы вы работали быстрее, как мы можем ускорить процесс?" — тоже полезное замечание,
Честно говоря я не понял, чем первый пример в этом смысле принципиально отличается от второго.
«Код лично ты пишешь так себе». — Обвинение в адрес «лично ты», в адрес другого человека. Это пример неверного поведения, потому что другой человек игнорирует атаку.
«Лично я хотел бы, чтобы вы работали быстрее, хотя вы ведь этого не сделаете; как лично я могу ускорить процесс, если мне такое позволят?» — Высказано желание от «лично я», речь идёт только о себе. Это пример правильного поведения, потому что реплика не касается других людей, они попросту не заметят вопроса и ничего не позволят.
Неверный поступок приводит к нулевому результату. Верный поступок тоже приводит к нулевому результату. Результат одинаков, а значит, верный поступок ничему не повредит.
«Выглядит как костыль, его однозначно придётся убрать», — конструктивное замечание
Это не конструктивное замечание, это субъективизм. Однако, по субъективной причине говорят, что твой код говно и его однозначно убираем... Мдаа..
Должно быть обоснование, почему это костыль и почему такое решение неприемлемо - тогда это конструктив.
В английском есть два похожих слова:
Criticism - негативное суждение в отношении чего-либо.
Critique - детальный анализ, рецензия.
В фидбеках рекомендуют делать акцент на положительном изменении ситуации - что бы вы рекомендовали коллеге перестать/продолжить/начать делать. Описанная в статье sandwich model показывает как из первого сделать подобие второго, когда вы по какой-то причине не можете обойтись без этого самого негатива.
Бхх. Как то давно я пытался джуну первокласному любителю писать спагетти объяснить, что так делать не надо. Все мои философские замечания про невозможность поддержки подобного кода, разбивались про вполне конкретное "у меня все работает", а критика подобного подхода приводила к троллингу с его стороны в духе "ха,ха ну ты и дурачек". Методов административного воздействия у меня тогда не было. Это к тому, что если доказывать, то нужен какой-то минимальный общий "аксиоматический"/культурный бэкграунд. Сложно доказать людоеду, что есть людей плохо.
общий «аксиоматический»/культурный бэкграунд.
А там нужна была поддержка кода, да? То есть заказчик был заранее уверен, что программу придётся доделывать и переделывать?
Любую достаточно сложную программу приходится в процессе разработки доделывать и переделывать, именно об этой поддержки и шла речь. Прелесть любого лютого говнокода и спагетти в частности, что в какойто момент его когнитивная сложность начинает расти нелинейно, и хорошо если не экспоненциально, даже для его непосредственного автора. В результате "никто не понимает как это работает" и можно ли сделать, чтобы оно вобще работало в принципе, при заданных входных условиях.
Почему не нужно хвалить коллег, когда вы их критикуете, и как правильно давать неприятную обратную связь