• 转行挨批的一天:什么垃圾方案,连问题都没搞清楚


    今天又是痛苦的一天,写的技术方案被评不切合实际,方案目标偏离用户需求。

    遇到的困境:

    1.现场调研,客户面临的问题实在是太简单,简单到无法用个完整的解决方案去解决,差不多是平台系统建成,发出一个通知就能解决客户问题的需求。

    2.在现场调研时,没有去引导客户的想法往自己的方案上靠,也是导致自己写方案的时候非常被动。往往你写完一整套方案,往往超出了客户的预期,而公司本身也不愿意在项目预算的不明确的情况下投入太大的精力去认真对待,你就夹杂在中间两头受气。

    以上种种情况,在后续的工作中该如何避免?

    解决方案如下:

    1.调研之前搞清楚该项目的5个问题:

    1. 项目背景是啥?(所有项目相关的信息,比如项目预算、项目目的)
    2. 项目的话事人是谁?充当什么角色?哪个层级的领导及其主要诉求是什么?
    3. 项目应用场景是什么?主要给谁用?主要使用的情况描述有哪些?现场具体有什么东西(比如待解决问题的对象的型号、规格、数量、行为等)?
    4. 项目主要解决的环节在哪里?涉及那些业务?要解决什么核心问题?
    5. 钱、钱、钱,重要的事情说三遍,做项目的场子是干啥的以及主要业务是干啥的?解决问题的决心有多大?愿意投入多少钱解决问题的决心有多

    2.后续搞工作时刻谨记的重点:

    1. 接收工作时,问清楚工作目标。白干是常有的事,但怎么让自己的工作价值最大化,合理摸鱼这是对我们而言非常重要的事情。
    2. 执行工作时,确定具体计划。咋还是说白干是常有的事,自己辛苦了半天,换来了你领导一句工作不负责,做事不认真。你就太冤了、太冤了。。。
    3. 反馈工作时,带着方案反馈。但凡让领导觉得你是一个积极主动、认真负责的人,你得把自己当奴才,上、中、下三策给他安排上,上册就是那种花费大量资源大干特干的那种,中策就是你当前的方案,下册就是花费少活儿干的也不好的那种。
    4. 总结工作,亮数据就对了。你是要恰饭的,说数据是让上面的人评估你的工作,让上面的人没事儿别来打搅你。
    5. 分享工作,说经验技巧。夸自己就完事儿,从工作中找原因找技巧,时刻准备文稿总结怎么夸自己。

    最后说一句,我太难了~

  • 相关阅读:
    js实现贪吃蛇游戏
    TCP协议IP网络音柱
    《DevOps实践指南》- 读书笔记(六)
    FFmpeg源代码:AVFormatContext相关接口
    传奇版本添加npc修改增加npc方法以及配置参数教程
    virtual box 导入vdi虚拟系统文件.
    LinkedHashMap实现LRU缓存cache机制,Kotlin
    OSN 1800 II TP机盒华为全新一代光层机盒
    模拟.NET应用场景,综合应用反编译、第三方库调试、拦截、一库多版本兼容方案
    50etf期权的隐含波动率是什么意思?最通俗易懂的解释!
  • 原文地址:https://blog.csdn.net/diguoweiwu/article/details/126720858