Comments 21
Поначалу все так щебечут, а потом рано или поздно начинают приСЛОНяться…
У нас отдел разработки сам решает, как и что нужно сделать...
Тогда понятно, почему у вас получается такой продукт… э-э-э, как бы это сказать получше — со странностями, что ли. Вроде, и неплохо местами, но весь интерфейс (как визуально, так и функционально) какой-то кусочный. С точки зрения работы с сервисом в целомЮ слишком много интуитивно неясных вещей. Чем-то смутно напоминает сцену: «К пуговицам претензии есть? К пуговицам — нет, пришиты насмерть, зубами не оторвешь!».
Тогда понятно, почему у вас получается такой продукт… э-э-э, как бы это сказать получше — со странностями, что ли. Вроде, и неплохо местами, но весь интерфейс (как визуально, так и функционально) какой-то кусочный. С точки зрения работы с сервисом в целомЮ слишком много интуитивно неясных вещей. Чем-то смутно напоминает сцену: «К пуговицам претензии есть? К пуговицам — нет, пришиты насмерть, зубами не оторвешь!».
Хз, хз я вот как-то работал и было неплохо (работал год назад) есть свои плюсы, свои минусы нов общем не плохо.
А вот скажем возьмите известную Jira там я там каждый раз оказываясь на главной ищу 30-50 секунд только нужную ссылку ибо там каша, все мелко и главное не выделено. вообще скажем не выделены главные вещи, все сливается (версия JIRA 3.12 если что), работал ещё с assembla тоже понравилось по приятней интерфейс. basecamp тоже по приятней.
А вот скажем возьмите известную Jira там я там каждый раз оказываясь на главной ищу 30-50 секунд только нужную ссылку ибо там каша, все мелко и главное не выделено. вообще скажем не выделены главные вещи, все сливается (версия JIRA 3.12 если что), работал ещё с assembla тоже понравилось по приятней интерфейс. basecamp тоже по приятней.
Jira новой версии (не помню какая — та, которая была актуальной во 2-й половине 2010 г.) — это да. По сравнению с предыдущей версией, при первом же её чтении возникло стойкое желание оформить вёрстку как полагается — с выделениями ключевых блоков текста. И, недолго думая, сделал юзерстили для неё — Jira Usable. После этого стало нормально, привычно работать.
С Мегапланом (по теме) — поработал немного. Надо сказать, что Jira/Redmine несколько лучше, лаконичнее, что ли. В Мегаплане отвлекают не очень ясные названия разделов и рисунки, окганиченность навигации. Приходится ходить как бы по неявно указанным дорожкам и никак иначе. Например, чтобы найти сотрудника, нельзя отыскать поля «Поиск», а обязательно найти слово «Сотрудники». После чего — обязательно догадаться, как происходит фильтрация. Он, в общем, функции свои выполняет, но ощущение жёстко поставленных рамок. В том же Redmine — меню и поле поиска с категориями (проектами) всегда на виду, плюс уточняющие меню слева, позволяющие перейти на смежные срезы просмотра (Задачи — Сводка или Задачи — Мои задачи и т.д.). Jira, Trac — по тому же принципу. Нет смысла ужесточать рамки и осложнять хождение по карте проектов и задач. Приветствовалось бы обратное. Например, поиск по произвольным фразам из задач и комментариев.
С Мегапланом (по теме) — поработал немного. Надо сказать, что Jira/Redmine несколько лучше, лаконичнее, что ли. В Мегаплане отвлекают не очень ясные названия разделов и рисунки, окганиченность навигации. Приходится ходить как бы по неявно указанным дорожкам и никак иначе. Например, чтобы найти сотрудника, нельзя отыскать поля «Поиск», а обязательно найти слово «Сотрудники». После чего — обязательно догадаться, как происходит фильтрация. Он, в общем, функции свои выполняет, но ощущение жёстко поставленных рамок. В том же Redmine — меню и поле поиска с категориями (проектами) всегда на виду, плюс уточняющие меню слева, позволяющие перейти на смежные срезы просмотра (Задачи — Сводка или Задачи — Мои задачи и т.д.). Jira, Trac — по тому же принципу. Нет смысла ужесточать рамки и осложнять хождение по карте проектов и задач. Приветствовалось бы обратное. Например, поиск по произвольным фразам из задач и комментариев.
Тут закралась неточность. Имелось в виду, что решения принимаются внутри компании и диктуются желанием сделать продукт лучше для пользователей. В противовес ситуации, когда всё решает заказчик.
Насчёт кусочности — спорить не буду, тут вы правы. Быстрое развитие даёт о себе знать: кое-где экспериментируем с интерфейсами, выпустили отчёты в бета-режиме, бету продаж опять же. Вторую половину года намерены посвятить работе над ошибками и свести всё к единым стандартам, благо пользовательского опыта собрано достаточно.
Если есть реальные замечания, мешающие работать, и желание ими поделиться, пожалуйста, пишите прямо мне в личку. Постараюсь ответить всем.
Насчёт кусочности — спорить не буду, тут вы правы. Быстрое развитие даёт о себе знать: кое-где экспериментируем с интерфейсами, выпустили отчёты в бета-режиме, бету продаж опять же. Вторую половину года намерены посвятить работе над ошибками и свести всё к единым стандартам, благо пользовательского опыта собрано достаточно.
Если есть реальные замечания, мешающие работать, и желание ими поделиться, пожалуйста, пишите прямо мне в личку. Постараюсь ответить всем.
Когда речь идет о тиражируемом продукте, то это вполне естественная ситуация, что нет какого-то внешнего заказчика, и компания-разработчик сама определяет, как и куда развивать свой продукт.
Но в топике, по-моему, совершенно четко сказано об отсутствии некоего внутреннего «директора-заказчика», т.е. начальника для разработчиков, который определяет концепцию и развитие продукта. Чувствуются интонации программера, которому довелось поработать под начальством не очень умного (мягко скажем) начальства.
Я сам и разработчик, и начальник, бывал неоднократно и в рои заказчика, и в роли исполнителя, и тоже считаю себя творческой личностью. Но я очень хорошо знаю, к чему может приводить плохо управляемый поток творческой энергии.
А из реальных замечаний ниже уже комент есть, мы сталкивались с тем же самым — непредсказуемая работа уведомлений и очень непрозрачная логика видимости/невидимости отдельных итемов (задач, документов, обсуждений). И постоянно возникает ощущение, что при разработке вы отталкиваетесь от функционала, а не от юзкейсов. Т.е. функция, вроде, есть, и она даже работает. Но в повседневной работе слишком много телодвижений приходится делать, чтобы получить желаемый результат.
Но в топике, по-моему, совершенно четко сказано об отсутствии некоего внутреннего «директора-заказчика», т.е. начальника для разработчиков, который определяет концепцию и развитие продукта. Чувствуются интонации программера, которому довелось поработать под начальством не очень умного (мягко скажем) начальства.
Я сам и разработчик, и начальник, бывал неоднократно и в рои заказчика, и в роли исполнителя, и тоже считаю себя творческой личностью. Но я очень хорошо знаю, к чему может приводить плохо управляемый поток творческой энергии.
А из реальных замечаний ниже уже комент есть, мы сталкивались с тем же самым — непредсказуемая работа уведомлений и очень непрозрачная логика видимости/невидимости отдельных итемов (задач, документов, обсуждений). И постоянно возникает ощущение, что при разработке вы отталкиваетесь от функционала, а не от юзкейсов. Т.е. функция, вроде, есть, и она даже работает. Но в повседневной работе слишком много телодвижений приходится делать, чтобы получить желаемый результат.
Ну что ж, список кинул в личку, продублирую и здесь на обозрение всем:
Это лишь небольшая часть, но очень важная для меня в частности. Буду рад ответам.
- Комментарии → Не резать код ([removed]) →
- Таск-менеджер → Не перекидывать на главную после удаления задачи →
- Таск-менеджер → Возможность выбора постановщика при создании задачи →
- Таск-менеджер → Публичные шаблоны задач и проектов →
- Сотрудники → Возможность редактирования даты бонуса →
Это лишь небольшая часть, но очень важная для меня в частности. Буду рад ответам.
Согласен. работа самого мегаплана довольно сумбурна. некоторые моменты прям лапочка.
а иногда думамешь, как вообще думал разработчик.
Например из последнего: Проект в списке не видет сотрудник, а через поиск находит, всё потому что в проекте нет задач.
или например, если не возможно создать трумбмэйл, то страница не открывается совсем. при этом задачу удалить невозможно. при этом обращение в техподдержку как удалить такую задачу(т.е. не восстановить тумбочку а именно удалить такую задачу), приводит к группе запросов в pgsql которые всё равно не помогают, потому что база судя по всему, сложна для понимания всем программистам компании.
или например в один прекрасный день перестала ходить почта. перестала она ходить потому что прав на какую то директорию не хватило(где-то внутри крона)все анализаторы говорят что всё работает.
а оказалось что ошибка сыпется в почту на сервере того юзера из под того пользователя которого он работает.
И вроде бы всё логично и даже так и должно работать. вот только этой логика не совсем знакома тех.поддержке и юзеру.
а иногда думамешь, как вообще думал разработчик.
Например из последнего: Проект в списке не видет сотрудник, а через поиск находит, всё потому что в проекте нет задач.
или например, если не возможно создать трумбмэйл, то страница не открывается совсем. при этом задачу удалить невозможно. при этом обращение в техподдержку как удалить такую задачу(т.е. не восстановить тумбочку а именно удалить такую задачу), приводит к группе запросов в pgsql которые всё равно не помогают, потому что база судя по всему, сложна для понимания всем программистам компании.
или например в один прекрасный день перестала ходить почта. перестала она ходить потому что прав на какую то директорию не хватило(где-то внутри крона)все анализаторы говорят что всё работает.
а оказалось что ошибка сыпется в почту на сервере того юзера из под того пользователя которого он работает.
И вроде бы всё логично и даже так и должно работать. вот только этой логика не совсем знакома тех.поддержке и юзеру.
Да, и забыл спросить: а маркетинговую политику у вас, случайно, не программисты определяют? Знаю, что неоднократно были просьбы сделать единую стравнительную таблицу разных версий (комплектов) Мегаплана, но вы упорно не желаете этого делать. Вы не понимаете, что клиентов так теряете?
Ну зачем вы так, всё в кучу смешали. Программисты делают свою работу, маркетологи — свою. Иногда возникают совместные обсуждения и обмен мнениями, но в целом каждый делает то, что должен.
Сейчас готовится к запуску новая версия сайта и сравнительную таблицу я в тестовой версии уже видел.
Сейчас готовится к запуску новая версия сайта и сравнительную таблицу я в тестовой версии уже видел.
Вообще-то, в этом комменте я вопрос задавал. И да, была в нем легка ирония.
Про сравнительную таблицу: решил я как-то заюзать Мегаплан в одном проекте, где участники были удалены друг от друга. Потратил какое-то время, пытаясь понять, какая же версия нам нужна, не понял, плюнул и ушел. Как-то в компании рассказал об этом, и сразу нашлось двое знакомых, которые точно так же споткнулись на этом. Я даже в реформал вам написал, но тут же получил комент от одного из юзеров, мол, мы об этом еще полгода назад просили, но получили ответ: «мы не продаем отдельные функции, мы продаем версии целиком, поэтому такая таблица не нужна». Трудно поверить, что грамотные маркетологи могли так ответить
Про сравнительную таблицу: решил я как-то заюзать Мегаплан в одном проекте, где участники были удалены друг от друга. Потратил какое-то время, пытаясь понять, какая же версия нам нужна, не понял, плюнул и ушел. Как-то в компании рассказал об этом, и сразу нашлось двое знакомых, которые точно так же споткнулись на этом. Я даже в реформал вам написал, но тут же получил комент от одного из юзеров, мол, мы об этом еще полгода назад просили, но получили ответ: «мы не продаем отдельные функции, мы продаем версии целиком, поэтому такая таблица не нужна». Трудно поверить, что грамотные маркетологи могли так ответить
топик — реклама собственных вакансий?
Чтобы увидеть вторую картинку, необходимо быть авторизованным в мегаплане?
Не видно вторую картинку (а вдруг там секретный план).
И, собственно, вопрос: у вас тоже дефицит разработчиков на рынке? (у нас, например, конкуренция зарплатами среди работодателей почти не работает).
И, собственно, вопрос: у вас тоже дефицит разработчиков на рынке? (у нас, например, конкуренция зарплатами среди работодателей почти не работает).
Почему-то топики с такой темой ничего, кроме ассоциаций с «программисты — животные» не вызывают :(
Нет привязки к конкретным часам работы — жаворонки приходят утром, совы — как выспятся, и никто не стоит с секундомером. Работа идет в scrum — а это значит командная работа, ответственность за результат, жизнь в продукте.
Если не секрет, как в рамках свободного графика работаете с такими практиками скарама как daily stand-up meeting? Оно как бы в начале рабочего дня производится. А если часть команды приходит в 9, часть в 11 а часть в 15 — то непонятно что делать.
Хороший кофе дейтвительно очень важен! :)
Sign up to leave a comment.
Почему в Мегаплане программистам живется хорошо?